On Jul 7, 2013, at 1:08 AM, Vincent Habchi <vi...@macports.org> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
