gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: big memory leak in GSString


From: David Chisnall
Subject: Re: big memory leak in GSString
Date: Sun, 13 Jan 2013 17:19:14 +0000

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]