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
