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).