Re: The cost of using objects rather than plain C variables
Re: The cost of using objects rather than plain C variables
- Subject: Re: The cost of using objects rather than plain C variables
- From: Jens Alfke <email@hidden>
- Date: Sun, 07 Jul 2013 10:48:38 -0700
On Jul 7, 2013, at 1:08 AM, Vincent Habchi <email@hidden> wrote:
> My initial reasoning was very (too) simple: I have a 20 MB file made up of strings, if I store those strings in objects, even with a small overhead, it should not top 30 or 40 MB. It turned out I was plainly wrong, at least the way I implemented it.
Storing small values in individually malloc’ed heap blocks is relatively expensive. A malloc block has a minimum size of 16? bytes, is always allocated on a padded boundary (4-byte or 16-byte?) and has at least four? bytes of overhead for heap-management metadata. [Don’t trust those numbers; they’re from memory and may be obsolete or wrong.] Moreover, the malloc() and free() calls have nontrivial CPU overhead.
It’s almost* always going to be a lot cheaper to store little fixed-size values/objects in C-style arrays. (If you’re willing to get down with Obj-C++, the std::vector class is useful for this.)
Note: This overhead really only becomes noticeable when one is allocating huge numbers of tiny objects. In most circumstances it’s not noticeable; but your specific case is one where it does cause problems.
—Jens
* The exception is certain types of NSNumber, which are magically stored as tagged pointers rather than malloc’ed blocks. This makes them virtually free to allocate. In 32-bit processes I think this only applies to booleans and smallish integers. In 64-bit there’s a lot more room inside a pointer so more values are stored tagged; certainly larger ints, and I’m guessing 32-bit floats.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden