Re: [Gnustep-cvs] r33146 - in /libs/gui/trunk: Source/ TextConverters/RTF/ Tools/

[Quentin Mathé]

Le 29 mai 2011 à 07:42, Richard Frith-Macdonald a écrit :

> On 27 May 2011, at 13:42, David Chisnall wrote:
> 
>> On another issue ... you say:
>> Also deleted some [pool release] lines just before exit() or return-from-main
>> statements.  These cause objects to be swapped in and destructors to be run 
>> to
>> no benefit (the OS will reclaim this memory without requiring stuff to be
>> swapped in when the process exits).
> 
> I seem to remember this philosophical point being raised before on the 
> mailing lists, and someone saying that this was a bad thing to do.
> Yes, skipping 'cleanup' on program exit is more efficient, but are machines 
> really so slow that this is an issue?

Some Cocoa apps such as Safari can takes one or several minutes to quit when 
they have been under heavy usage (on a MacBook core duo). For example, time to 
time I have more than ~50 tabs or windows in Safari. I suppose the time spent 
to quit is mostly related to the time it takes to free all the memory that was 
allocated.

>  I think it was pointed out that doing the release helped with tracking down 
> memory leaks and exposing bugs in the code which would show up when the 
> objects are released.  Was some consensus reached on this?  I don't recall 
> anyone particularly agreeing with skipping the releases (though I wasn't 
> involved in the discussion and may well have missed reading some of it).

There was no consensus, but both David and I agree that the best would be to 
have a "debug" mode where the all the memory is freed on quit, and a "release" 
mode where this is skipped.

For this commit, it seems that David only removed [pool release] when something 
gets wrong and the application exists abruptly, but not when the application 
terminates normally. See 
http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Tools/make_services.m?r1=33146&r2=33145&pathrev=33146
I think I would prefer to get all the memory freed even when something gets 
wrong… Unless the behavior suggested above is implemented.

Cheers,
Quentin.