Mail Archives: cygwin/2006/08/13/23:20:50
> From: "emacs user" <emacs_user AT hotmail DOT com>
> Bcc:
> Date: Sun, 13 Aug 2006 17:32:38 -0400
>
> >From: Eli Zaretskii <eliz AT gnu DOT org>
>
> >If I don't miss anything, it remains to be explained why the OP didn't
> >see problems with normal buffers. Could the OP please try visiting
> >several large text files, then kill their buffers, invoke the
> >`garbage-collect' function ("M-x garbage-collect RET"), and see if the
> >memory footprint returns to its original value?
>
> starting emacs -Q: 12,832k
> editing a large test file (43,085,936), emacs memory goes up to 55,028k
> killing : emacs uses 13,070
> and M-x garbage-collect 13,100 or so,
>
> so far it seems that tmemory is returned.
Yes.
> however, using emacs a bit more,
> opening and killing buffers, eventually does lead to memory increase even
> after I kill all buffers and do garbage-collect.
Assuming that ``using a bit more'' loads some Lisp packages, this is
normal. Also, font-lock, which works in the background, adds text
properties to buffers, which also uses up some memory.
> >A few more tests come to mind:
> >
> > . Put a breakpoint in sbrk and in mmap, and find out which one is
> > being called when normal text files and image files (both small
> > and large) are visited.
>
> could you please write which .c files and which routines should I be looking
> at slightly more specifically? thanks...
These are library functions, so no .c files are involved. Just
(gdb) break sbrk
(gdb) break mmap
then visit text and image files as suggested and see which of these
breakpoint actually breaks.
> > . Visit many small image files (smaller than 256K) and see whether
> > the memory is being returned to the OS.
Same here.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -