Re: Memory again

[Carsten Mattner]

On Sat, Nov 26, 2011 at 9:31 PM, Eli Zaretskii <address@hidden> wrote:
>> Date: Sat, 26 Nov 2011 20:02:27 +0100
>> From: Carsten Mattner <address@hidden>
>> Cc: address@hidden, address@hidden
>>
>> On Sat, Nov 26, 2011 at 5:23 PM, Eli Zaretskii <address@hidden> wrote:
>> >> Date: Sat, 26 Nov 2011 15:58:49 +0100
>> >> From: Carsten Mattner <address@hidden>
>> >> Cc: address@hidden
>> >>
>> >> Does emacs fear the memory may be used by someone else
>> >> and hold onto what it claimed?
>> >
>> > It doesn't, or at least shouldn't.  When enough memory has been
>> > reclaimed by GC, it should give it away to the system.  At least on
>> > some systems, I actually see that in action, after killing a large
>> > buffer.
>>
>> As it's at 56.1megs at the moment after having left it open
>> for a couple more hours, I guess that Dmitry's heap fragmentation
>> explanation sounds most likely.
>
> If you start a fresh Emacs and visit a very large file, do you see the
> footprint increase by approximately that file's size?  And if you then
> kill the buffer visiting the file, do you see the footprint go down
> back to almost what it was after startup?

Totally unscientific data:
After fresh startup: 21MB
Loading xx .erl file: 21.5MB
Kill buffer: 21.7MB
Load 13499b .erl file again: 21.8MB
Kill buffer: 21.7MB
Load 13499b .erl file again: 22MB
Kill buffer: 21.8MB
Load 13499b .erl file again: 22.1MB
Kill buffer: 22.3MB
Load 13499b .erl file again: 22.2MB
Kill buffer: 22.4MB
Load 13499b .erl file again: 22.3MB
Kill buffer: 22.4MB
Load 13569b .erl file: 22.3MB
Kill buffer: 22.5MB

---------------

fresh startup without Ido: 21.2MB or 21.1MB
C-x C-f: 21.3MB
load 13499b .erl file: 21.3MB
kill buffer: 21.4MB
reload same .erl file: 21.5MB
kill buffer: 21.6MB
reload same .erl file: 21.7MB first then 21.6MB then 21.5MB
kill buffer: 21.7MB first then 21.6MB
reload same .erl file: 21.7MB first then 21.6MB
kill buffer: 21.7MB first then N/A as I had pressed C-x C-f and
then pressing C-g made Emacs.app crash. sorry :(, it sometimes crashes
on C-g on Mac OS X.

If we can come up with some automation to trace and save
data, I'd be glad to collect that.

>> I'd like to not guess but help find potential issues which
>> can be corrected.
>>
>> How can I instrument/help find leaks or errors in the memory
>> manager?
>
> I'd start by showing the value returned by `garbage-collect' and
> comparing it with the value after startup.

Where am I supposed to see the output of (garbage-collect)?
Use an elisp buffer and make it print the result?
Or in the Messages buffer which I usually kill on startup and
disable by setting message-log-max to nil.