On Sun, Dec 14, 2008 at 5:38 PM, Filip van der Meeren <fi...@code2develop.com> wrote: > > On 14 Dec 2008, at 23:27, Ken Thomases wrote: > >> On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote: >> >>> If your system doesn't crash/hangs before you can stop it, then you will >>> see that the app is consuming memory like the Americans are consuming oil. >>> And according to me, my program respects the Memory Management rules. So >>> I say there is a bug. >> >> Then you misunderstand. Nothing in the Memory Management rules will >> protect you, your program, or the system against your program consuming >> large amounts of RAM or VM. >> > > The Memory Management won't protect me indeed, but still, NSNumber is the > basic foundation of our OS, I know dozens of ways to create the object > without autoreleasing it inside somewhere. > There has to be a better way to do this, this isn't just some other virtual > machine that releases objects when its pool is full. This is native, no > garbage collector is going to save us! > That is why I think that the basic building blocks of our framework should > be able to create themselves without putting a big restraint on the system.
There is no big restraint on the system. If you have a long-running loop such as in your example code then you *must* create and destroy inner autorelease pools within the loop if you intend to keep memory consumption at reasonable levels. This is documented and discussed, and should hardly be a surprise. That you alloc/init your objects instead of using convenience constructors is no surprise. You *cannot* rely on code you do not control not to autorelease objects just because you're using "direct" methods. Follow the rules. It's the only way. The rules say that you need an autorelease pool in a tight, long-running loop. You can't ignore that just because you think you shouldn't need it in this particular case. Mike _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
