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: "T.J. Usiyan" <email@hidden>
- Date: Sat, 06 Jul 2013 23:24:00 -0700
The short answer is yes the overhead of an object versus a primitive
value is huge.
The longer answer is that however tiny you think the difference might
be, you need to multiply it by somewhere between 200,000 and 600,000
to really get a sense for the difference in context. For the same
reasons that I would almost never consider representing each sample in
an audio buffer with an object you probably don't even want to
consider representing each vertex, normal, or triangle with an object.
The *actual* difference in size between an object and a primitive is
negligible in many cases but when we are trying to represent thousands
of objects or more we make that difference much more relevant.
If the difference were
1kb in memory
1 object would mean 1kb difference
10 objects would mean 10kb difference
1024 objects would mean 1mb difference.
200,000 objects would mean 200 mb difference (which lines up with
your findings pretty well)
TJ
On Sat, Jul 6, 2013 at 11:06 PM, Vincent Habchi <email@hidden> wrote:
> Hi everybody,
>
> the tiny iOS app I work on currently begins by decoding 3D data in the form of a TIN: vertices, normals then triangles. There are about 200 000 of the two formers, and 400 000 of the latters (needless to say, at a later stage, I am going to improve speed by using some kind of tiling and mipmaping at the geometric level, though I am getting surprisingly good performance with this crude model, even on an iPhone 4, i.e. ca 15 fps). The syntax of the TIN file is very simple: coma separated components, and a specific header for each of the three sections.
>
> At first, the TIN file didn’t include the exact number of vertices/normals/triangles, so I had to decode the whole file in order to know how large a buffer I should allocate to store each of the three data types. Meanwhile I did record the data in NSMutableArrays. But I ended up eating more than 200 MB of memory doing so, even with ARC enabled! > 200 MB for three mutable arrays, each with a corresponding number of arrays of three strings each (the original TIN file is about 17 MB).
>
> Needless to say, that was more than excessive. Thus, I backed off, decided to add the number of primitives in the file header, in order to be able to use malloc right after the beginning of the process, and substituted all Obj-C oriented calls by plain C functions (e.g. instead of [myMutableArray add:[[NSString stringFromCString:… encoding:…] componentsSeparatedBy:@", "]], I just wrote: sscanf (myLine, "%f, %f, %f", &t [0], &t [1], &t [2])) and this time, the memory usage didn’t top 21 MB, which seems reasonable.
>
> How come I get such a large discrepancy in memory usage between the two solutions? Is the overhead of Cocoa object so huge?
>
> Thanks!
> Vincent
>
>
> _______________________________________________
>
> 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
_______________________________________________
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