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
