Re: The cost of using objects rather than plain C variables
Le 12 juil. 2013 à 08:41, Vincent Habchi a écrit : > Hi! > > Sorry for this late answer, I was a bit swamped lately. > >> NSData wouldn't let you, but NSMutableData would, with methods like >> appendBytes:length:, appendData:, increaseLengthBy:, etc. The underlying >> buffer might have to move around if it cannot be extended in place, just as >> it would if you use C realloc() calls. > > In fact, I overlooked that completely. I just fear building a buffer from > zero to something like 400,000 * 3 * 4 bytes = just under 5 MiB would imply > too many moves as you mention. If you know how large your data will be and want to avoid the realloc cost, you can just create your mutable data using -initWithCapacity: . And even if the size end up to be larger than your initial capacity, the mutable data will do the right thing and increase the capacity. > Now, I am anyway moving towards a binary file that would be fed directly into > the buffer rather than needing decoding, and partitioning it into several > chunks in order to optimize the number of triangles displayed. I think I’ll > use NSData to store these chunks. > > Thanks to all for the precious help! > Vincent > -- Jean-Daniel ___ 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
Re: The cost of using objects rather than plain C variables
Hi! Sorry for this late answer, I was a bit swamped lately. > NSData wouldn't let you, but NSMutableData would, with methods like > appendBytes:length:, appendData:, increaseLengthBy:, etc. The underlying > buffer might have to move around if it cannot be extended in place, just as > it would if you use C realloc() calls. In fact, I overlooked that completely. I just fear building a buffer from zero to something like 400,000 * 3 * 4 bytes = just under 5 MiB would imply too many moves as you mention. Now, I am anyway moving towards a binary file that would be fed directly into the buffer rather than needing decoding, and partitioning it into several chunks in order to optimize the number of triangles displayed. I think I’ll use NSData to store these chunks. Thanks to all for the precious help! Vincent ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 8, 2013, at 18:04 , Jens Alfke wrote:
>
> On Jul 7, 2013, at 1:37 PM, Frederick Bartram wrote:
>
>> Have you tried using NSData to store C-arrays?
>
> Or alternatively use NSPointerValue to wrap a pointer to a malloc’ed C array
> as an object.
It seems to me that an array of float is worth a dedicated object, for example
MPWRealArray, SMUGRealVector or the arrays in FScript:
@interface MPWRealArray : MPWObject
{
NSUInteger capacity;
NSUInteger count;
float *floatStart;
}
This is really easy to create yourself, the key insight is that you don't have
to use the pre-defined objects that Apple gives us, especially when performance
is a concern you are frequently better of rolling your own. I benchmarked
this a little while ago, and creation a 1 element real array was 1000 (one
thousand) times faster than creating a 1 element NSArray of (float)
NSNumbers. It also uses 5-10 times less memory, and if needed you can define
homogenous operations on the array, using tight C loops or the Accelerate
framework. For example, summing such an array can be done as follows:
-(float)vec_reduce_sum
{
float theSum=0;
vDSP_sve ( floatStart, 1, &theSum, count );
return theSum;
}
That's roughly 200 times faster than summing an NSArray of NSNumber.
Cheers,
Marcel
https://github.com/mpw/MPWFoundation
https://bitbucket.org/liscio/smugmath/
http://www.fscript.org
___
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
Re: The cost of using objects rather than plain C variables
On 8 Jul 2013, at 18:14, Andy Lee wrote: > On Jul 8, 2013, at 1:08 PM, Boyd Collier wrote: >> Your suggestion sounded worth learning about, but it appears that there's no >> such creature as NSPointerValue. > > I'm guessing Jens meant +[NSValue valueWithPointer:]. > >> Did you perhaps mean NSPointerArray? > > I'm guessing not, since NSPointerArray is for containing an array of objects > (like NSArray does), not scalars. NSPointerArray is perfectly happy with — and designed for — non-objects, provided they're the same size as a pointer. ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 8, 2013, at 11:08 AM, Boyd Collier wrote: > Your suggestion sounded worth learning about, but it appears that there's no > such creature as NSPointerValue. Did you perhaps mean NSPointerArray? I suspect it was instead NSValue and pointerValue/setPointerValue to which he was referring. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 8, 2013, at 12:30 PM, Vincent Habchi wrote: > On 8 juil. 2013, at 18:04, Jens Alfke wrote: >> On Jul 7, 2013, at 1:37 PM, Frederick Bartram wrote: >> >>> Have you tried using NSData to store C-arrays? > > No, since my initial problem was to be able to extend the buffer as the > number of primitive read grew. NSData would not do that. NSData wouldn't let you, but NSMutableData would, with methods like appendBytes:length:, appendData:, increaseLengthBy:, etc. The underlying buffer might have to move around if it cannot be extended in place, just as it would if you use C realloc() calls. --Andy ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 8, 2013, at 1:08 PM, Boyd Collier wrote: > Your suggestion sounded worth learning about, but it appears that there's no > such creature as NSPointerValue. I'm guessing Jens meant +[NSValue valueWithPointer:]. > Did you perhaps mean NSPointerArray? I'm guessing not, since NSPointerArray is for containing an array of objects (like NSArray does), not scalars. --Andy ___ 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
Re: The cost of using objects rather than plain C variables
Your suggestion sounded worth learning about, but it appears that there's no such creature as NSPointerValue. Did you perhaps mean NSPointerArray? On Jul 8, 2013, at 9:04 AM, Jens Alfke wrote: > > On Jul 7, 2013, at 1:37 PM, Frederick Bartram wrote: > >> Have you tried using NSData to store C-arrays? > > Or alternatively use NSPointerValue to wrap a pointer to a malloc’ed C array > as an object. > > —Jens > ___ > > 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/bcollier2%40cox.net > > This email sent to bcolli...@cox.net ___ 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
Re: The cost of using objects rather than plain C variables
On 8 juil. 2013, at 18:04, Jens Alfke wrote: > On Jul 7, 2013, at 1:37 PM, Frederick Bartram wrote: > >> Have you tried using NSData to store C-arrays? No, since my initial problem was to be able to extend the buffer as the number of primitive read grew. NSData would not do that. Alternatively, I could have allocated NSData as memory chunks. > Or alternatively use NSPointerValue to wrap a pointer to a malloc’ed C array > as an object. This one I wasn’t aware of. Vincent ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 1:37 PM, Frederick Bartram wrote: > Have you tried using NSData to store C-arrays? Or alternatively use NSPointerValue to wrap a pointer to a malloc’ed C array as an object. —Jens ___ 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
Re: The cost of using objects rather than plain C variables
> Is there any hope in the future to be able to store simple types like int or > floats in NSArrays? Have you tried using NSData to store C-arrays? *- * Frederick Bartram * PGP key id: 0x63fa758 keyserver: http://keyserver.pgp.com */ smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 1:08 AM, Vincent Habchi 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
Re: The cost of using objects rather than plain C variables
And while we're on the subject of speed, you're already dealing with threads, you're already prefixing the values with a count, if you get to a format where values in the input file are fixed-length, then you can find sections 2 & 3 without reading 1 & 2, so you could load the sections in parallel in different threads... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 10:38 AM, Vincent Habchi wrote: > Oh, just that since I moved from plain BSD/Qt3 to MacOS/Cocoa, I swore not to > write any line of C++ ever again. But that’s just a personal commitment ;) If Qt is the majority of your experience with C++, then I understand wanting to avoid it... > That’s what I plan for the next step: I’ll try to set up an automatic > translation from the ascii file as part of the build process. But I must > admit while I am pretty familiar with Makefiles, I have still to figure out > how to do that with Xcode (I suppose it’s not a hard task, it’s just that I > hadn’t time to slog on that). You add a script build phase to the target; in that script you do the conversion using whatever tools you want--I'd be tempted just to knock one out in C and invoke that from the script, but you may have other tools, or for all I know may have original data that's not yet text. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: The cost of using objects rather than plain C variables
Hi! You’re right to point that CFtypes exist: I often overlook these and that’s stupid of me. > Why? What's wrong with a simple array? Nothing. Well, at first, I was looking for a self expanding array, given that I didn’t know the size beforehand. > (Or, I would argue, though it's not a popular strategy, what's wrong with > std::vector?) Oh, just that since I moved from plain BSD/Qt3 to MacOS/Cocoa, I swore not to write any line of C++ ever again. But that’s just a personal commitment ;) > Now if you really want speed, stop converting from text to floats, convert > the file to a binary format containing floats before your users have to load > it. That’s what I plan for the next step: I’ll try to set up an automatic translation from the ascii file as part of the build process. But I must admit while I am pretty familiar with Makefiles, I have still to figure out how to do that with Xcode (I suppose it’s not a hard task, it’s just that I hadn’t time to slog on that). Have a nice Sunday, Vincent ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 1:33 AM, Vincent Habchi wrote: > Is there any hope in the future to be able to store simple types like int or > floats in NSArrays? Why? What's wrong with a simple array? (Or, I would argue, though it's not a popular strategy, what's wrong with std::vector?) Now if you really want speed, stop converting from text to floats, convert the file to a binary format containing floats before your users have to load it. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: The cost of using objects rather than plain C variables
Sent from my iPhone On 2013/07/07, at 16:33, Vincent Habchi wrote: > Hi! > Thanks to all for your quick and kind answers. > >> You're comparing apples to oranges. > > That’s a nice way of putting it! > >> You were storing strings for each numeric value, now you're storing doubles. > > Actually just floats, in order to save space. > >> You could have tried NSNumber objects instead of strings, but better would >> be a custom object which holds the three doubles as ivars. The former uses >> three objects per vertex, the latter using one object. > > I have tried NSNumber, but it didn’t save much space. I was unable to notice > any significant gain. > >> Before you go much further, though, are you sure the memory was not just a >> high-water mark due to accumulation of autoreleased objects? ARC isn't >> magic. It doesn't relieve you of _all_ need to think about memory >> management and the proper deployment of autorelease pools is one of the >> things you still have to consider. > > I have put an @autorelease pool around the decoding code, but it didn’t > change anything. You’re right, I think: the culprit is that the runloop never > gets any opportunity to complete, so the autorelease pool cannot be drained. > At a certain point, I receive a memory warning and shut all down. If I had > run the decoding on a background thread, for example with [self > performSelectorInBackground: withObject:] (which I ended up doing anyway, > because I wanted to animate a UIProgressBar to keep the user informed of what > was going on), would it have solved this issue? >> >> All of that said, though, it's perfectly reasonable to use C structs and >> arrays for large collections of simple data types. I would not expect that >> Cocoa objects, used sensibly, would be 10x larger (a.k.a. 90% wasteful). > > I plainly agree my initial scheme could have been vastly improved, even > sticking with Obj-C objects, but I was really struck by the figures I got. Is > there any hope in the future to be able to store simple types like int or > floats in NSArrays? > http://www.cocoaintheshell.com/2010/12/collections-integers-performances/ You can put pointers to plain old C types in a CFArray or CFMutableArray Always consider Core Foundation collections when looking for performance ___ 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
Re: The cost of using objects rather than plain C variables
Quincey, > Each NSString has at least 4 bytes of overhead (the 'isa' pointer); each > character is UTF-16; each object is a multiple of 16 bytes. Your values may > not fit in the remaining 12 bytes of the smallest object (an input format > something like '0.xe-nn', which isn't an unlikely format, wouldn't fit in 12 > bytes, even with only 1 significant digit in the mantissa). Well, I store GLshorts, GLfloats and GLints. The GLFloat is formatted like 0.xyztuvw I think, never more than seven digits after the decimal separator. But you’re right: I overlooked the UTF-16 default coding that doubles the size every ascii string. 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. > Actually, that's not so bad. 33-50MB instead of 20MB, for the objectified vs > scalar representation, isn't unbearable, I suspect. However, the C array of > scalars is probably the best choice. Well, the plain C way, I suspect, is also quicker. With the decoding taking around 30 seconds or so, I had better optimizing speed, too! Cheers and thanks a lot once again! Vincent ___ 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
Re: The cost of using objects rather than plain C variables
Hi! Thanks to all for your quick and kind answers. > You're comparing apples to oranges. That’s a nice way of putting it! > You were storing strings for each numeric value, now you're storing doubles. Actually just floats, in order to save space. > You could have tried NSNumber objects instead of strings, but better would be > a custom object which holds the three doubles as ivars. The former uses > three objects per vertex, the latter using one object. I have tried NSNumber, but it didn’t save much space. I was unable to notice any significant gain. > Before you go much further, though, are you sure the memory was not just a > high-water mark due to accumulation of autoreleased objects? ARC isn't > magic. It doesn't relieve you of _all_ need to think about memory management > and the proper deployment of autorelease pools is one of the things you still > have to consider. I have put an @autorelease pool around the decoding code, but it didn’t change anything. You’re right, I think: the culprit is that the runloop never gets any opportunity to complete, so the autorelease pool cannot be drained. At a certain point, I receive a memory warning and shut all down. If I had run the decoding on a background thread, for example with [self performSelectorInBackground: withObject:] (which I ended up doing anyway, because I wanted to animate a UIProgressBar to keep the user informed of what was going on), would it have solved this issue? > > All of that said, though, it's perfectly reasonable to use C structs and > arrays for large collections of simple data types. I would not expect that > Cocoa objects, used sensibly, would be 10x larger (a.k.a. 90% wasteful). I plainly agree my initial scheme could have been vastly improved, even sticking with Obj-C objects, but I was really struck by the figures I got. Is there any hope in the future to be able to store simple types like int or floats in NSArrays? Thanks again to all for your enlightening comments and kindness! Vincent ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 6, 2013, at 23:06 , Vincent Habchi wrote: > instead of [myMutableArray add:[[NSString stringFromCString:… encoding:…] > componentsSeparatedBy:@", "]], I just wrote: sscanf (myLine, "%f, %f, %f", &t > [0], &t [1], &t [2]) > How come I get such a large discrepancy in memory usage between the two > solutions? Is the overhead of Cocoa object so huge? It's not just the overhead of objects. According to the code you posted, you're storing floats instead of strings. Ken already elaborated on this conceptual answer, but I think the back-of-the-envelope calculation is enlightening: Each NSString has at least 4 bytes of overhead (the 'isa' pointer); each character is UTF-16; each object is a multiple of 16 bytes. Your values may not fit in the remaining 12 bytes of the smallest object (an input format something like '0.xe-nn', which isn't an unlikely format, wouldn't fit in 12 bytes, even with only 1 significant digit in the mantissa). In addition, there's at least a pointer's overhead per value in the array itself. That means you could be using 36 bytes per value in the objectified representation, versus 4 bytes in the C representation, or a factor of about 9. That's not so far off the factor of 10 you reported. If the above is a correct analysis, then using a NSNumber representation instead of a NSString would reduce the memory use to around 100MB. Using a custom object should, as Ken suggests, reduce this by another factor of somewhere between 2 and 3. Actually, that's not so bad. 33-50MB instead of 20MB, for the objectified vs scalar representation, isn't unbearable, I suspect. However, the C array of scalars is probably the best choice. ___ 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
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 1:06 AM, Vincent Habchi wrote: > 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? You're comparing apples to oranges. You were storing strings for each numeric value, now you're storing doubles. You could have tried NSNumber objects instead of strings, but better would be a custom object which holds the three doubles as ivars. The former uses three objects per vertex, the latter using one object. Before you go much further, though, are you sure the memory was not just a high-water mark due to accumulation of autoreleased objects? ARC isn't magic. It doesn't relieve you of _all_ need to think about memory management and the proper deployment of autorelease pools is one of the things you still have to consider. All of that said, though, it's perfectly reasonable to use C structs and arrays for large collections of simple data types. I would not expect that Cocoa objects, used sensibly, would be 10x larger (a.k.a. 90% wasteful). Regards, Ken ___ 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
Re: The cost of using objects rather than plain C variables
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 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 (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/griotspeak%40gmail.com > > This email sent to griotsp...@gmail.com ___ 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
The cost of using objects rather than plain C variables
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 (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
