Re: NSAutoreleasePool does not free all memory

[David Wetzel]

Richard Frith-Macdonald wrote

> Your problem is that you are using a relatively meaningless 
> statistic ... the reported memory
> size of an application is actually its *peak* size, not its current 
> size.  True, it's relevant
> to the swap space on your system, but not much else.

I understood that. You have some kind of "internal" free...

> In fact, your little test program demonstrates an unrealistic and 
> misleading situation when
> not using autorelease pools, and a more normal situation when using them.
> 
> I could change the autorelease pool implementation so that pools are not 
> cached and the memory
> they use is freed as soon as the pool is released, but the only effect 
> that would have on real
> programs is to slow them down slightly as each creation/destruction of a 
> pool would
> require a malloc/free overhead.

My guess is that this malloc/free overhead is much less (in time and CPU usage) 
than the overhead that we have when we are paging memory to disk.
The best way to do this would be a #ifdef SYSTEM_HAS_EFFICIENT_MALLOC in the 
Autorelease Pool source.
If my system's malloc would be inefficient, I could undef this #define.

Currently, we have no time to write an real benchmark program to compare the 
two versions :-(

---
   _  _
 _(_)(_)_  David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG,
  _/  \_   Fax +49 33056 82835 Phone +49 33056 82834
 (______)  http://www.turbocat.de/  dave@turbocat.de
           DEVELOPMENT * CONSULTING * ADMINISTRATION