On 13 Jan 2013, at 16:31, Fred Kiefer wrote: > I spend quite some time to analyse the cause of Pirmin's problem. In the end > it turned out that most of the memory was lost in the NSAutoreleasePool > itself. We cache the instances of this class and when code uses a lot of > objects with a single pool that pool will get huge and even after it is > released that addition memory will be kept. > This is fine in the normal usage of auto release pools where we expect that > the next usage will use about as many objects as a previous one. In Pirmin's > case the auto release pool that gets used at the start up becomes huge and > later on most of that memory is never needed again. > > Of course the best solution is to use multiple auto release pools during the > start up, for each operation a separate one. Still we should think about a > way to get rid of these monster pools, when a badly written program generates > one.
If you are building with libobjc 1.6.1 or later, GNUstep will use the autorelease pool implementation in the runtime. In my little benchmarks, this is rougly twice as fast as GNUstep Base's implementation (which, is about as fast as Apple's new-and-fast implementation, and about twice as fast as Apple's old one). David -- Sent from my brain _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
