memory usage

memory usage

[Stephen Berman]

With GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of
2007-06-03 on escher I have the impression, though I cannot be
certain, that memory usage is greater than it had been with earlier
builds.  My current session has been running for 13+ hours; top shows:

  PID %MEM  VIRT SWAP  RES CODE DATA  SHR nFLT nDRT S  PR  NI %CPU COMMAND
 4707 54.5  623m 349m 274m 1476 602m 8336 8928    0 S  17   0  0.0 emacs
 4015 10.5  145m  92m  52m 1516 114m 2596 1813    0 S  15   0  0.7 Xorg
 6545  7.3  174m 137m  36m 9520 137m 9.9m 1047    0 S  15   0  0.0 firefox-bin

and increasing steadily; about half an hour ago it was like this:

 4707 44.9  551m 324m 226m 1476 529m 8576 5149    0 S  18   0  0.0 emacs
 4015 10.7  141m  87m  53m 1516 110m 3260 1322    0 R  15   0  0.7 Xorg
 6545  7.8  174m 134m  39m 9520 137m  11m  951    0 S  15   0  0.0 firefox-bin

I currently have 28 buffers with a total size 4134853, 14 files, no processes.

M-: (memory-use-counts)
    => (19357612 63265 4733430 80473 141277128 1753754 446815 4002874)

M-: (memory-limit)
    => 754048

These are also increasing steadily (memory-full is still nil).

Are these numbers within normal bounds or cause for concern?

Steve Berman

Re: memory usage

[Stefan Monnier]

> 2007-06-03 on escher I have the impression, though I cannot be
> certain, that memory usage is greater than it had been with earlier
> builds.  My current session has been running for 13+ hours; top shows:

>   PID %MEM  VIRT SWAP  RES CODE DATA  SHR nFLT nDRT S  PR  NI %CPU COMMAND
>  4707 54.5  623m 349m 274m 1476 602m 8336 8928    0 S  17   0  0.0 emacs

200MB of resident size sounds a bit large.  Of course, it complely depends
on what you do with it.  Now that you mention it, I also see it here (my
main Emacs process is at more than 600MB of RSS).  Interestingly, I don't
see it with my Emacs process running Gnus (it's at 45MB of RSS).  Both of
them were started on June 6.

The 600MB process reports the appended info, which doesn't seem to justify
its size (even if you mutliply all the data by 2 since this is a 64bit
system and I'm not sure if the memory-report tool correctly takes it into
account).


        Stefan


Garbage collection stats:
((281590 . 116799) (22937 . 71) (14614 . 1238) 1039910 (23907 . 893363) (124 . 364) (18634 . 717) (37375 . 7234))

 =>	4505440+1868784 bytes in cons cells
	1100976+3408 bytes in symbols
	584560+49520 bytes in markers
	1984+5824 bytes in floats
	1043504+40152 bytes in intervals
	1196000+231488 bytes in string headers
	1039910 bytes of string chars
	382512 bytes of vector headers
	7146904 bytes of vector slots

Total bytes in lisp objects: 19200966 (live 17001790, dead 2199176)

Buffer ralloc memory usage:
54 buffers
7172725 bytes total (97049 in gaps)
      Size	Gap	Name

   2167440	1998	 *DOC*
   1202880	2000	loaddefs.el
   1018260	1885	ChangeLog | src
    897402	2000	 *Unicode Data*
    719303	2000	monnier@iro.umontreal.ca--first%emacs--monnier--0--patch-478
    199744	2000	fileio.c
    174892	2000	icicles-fn.el
    104255	2000	eval.c
    104170	1564	font-lock.el | trunk
    104170	1564	font-lock.el | release
     97227	1977	term.c
     78031	2000	complete.el
     35706	2000	icicles-var.el
     31587	1919	ChangeLog | lisp
     26356	2000	hi-lock.el
     21546	1896	vc-svn.el
     19836	1841	css-mode.el
     16021	129	*Completions*
     12699	2000	ChangeLog | admin
      7612	501	*MPC Albums*
      7202	2000	=tagging-method
      4754	2000	memory-usage.el
      3851	1650	*Messages*
      3464	574	*MPC Artists*
      3464	1919	 *code-converting-work*
      2909	2000	*grep*
      2846	2000	FOR-RELEASE
      2120	1646	*cvs* | trunk
      1772	2000	*Help*
       804	1196	*vc-diff*
       688	1782	*MPC Songs*
       604	1540	*Buffer Details*
       524	2000	*cvs* | release
       432	1595	*MPC Genres*
       304	2000	 *cvs-tmp*
       217	2000	*vc*
       200	1952	foo.sml
       191	2000	*scratch*
        86	1914	*VC-log*
        69	1960	*MPC-Status*
        58	1956	 *code-conversion-work*
        51	2000	*cvs-commit*
        25	1975	 *Echo Area 0*
         0	20	 *Minibuf-0*
         0	2000	 *Minibuf-1*
         0	2000	 *Minibuf-2*
         0	2000	 *Echo Area 1*
         0	2000	 *mpc*
         0	2000	 *mpc download*
         0	2000	 *mpc download*<2>
         0	2000	*Backtrace*
         0	2000	 *mpc download*<3>
         0	2000	 *cvs-tmp*<2>
         0	2000	 *mpc download*<4>

Re: memory usage

[Richard Stallman]

    With GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of
    2007-06-03 on escher I have the impression, though I cannot be
    certain, that memory usage is greater than it had been with earlier
    builds.

Earlier builds when?

Re: memory usage

[Stephen Berman]

On Wed, 13 Jun 2007 12:21:51 -0400 Richard Stallman <rms@gnu.org> wrote:

>     With GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of
>     2007-06-03 on escher I have the impression, though I cannot be
>     certain, that memory usage is greater than it had been with earlier
>     builds.
>
> Earlier builds when?

My most recent previous builds from CVS were 2007-04-30 (22.1.50),
2007-04-20 (22.0.98), 2007-04-08 (22.0.97), 2007-04-03 (22.0.96),
2007-02-08 (22.0.93), and 2007-01-22 (22.0.92).  On none of these did
I notice the large and relatively quickly growing memory footprint I
reported.  However, I also haven't seen this consistently with my
current CVS build, nor with my build of Emacs 22.1 from 2007-06-02.
I've been alternating between the latter two since building them.
I'll probably update from CVS again soon.  In any case, I'll keep
monitoring the memory usage.

Steve Berman

Re: memory usage

[Richard Stallman]

Can you try running for the next few weeks with the build from 4/30
to confirm that this problem does NOT happen?

Re: memory usage

[Stephen Berman]

On Thu, 14 Jun 2007 12:19:53 -0400 Richard Stallman <rms@gnu.org> wrote:

> Can you try running for the next few weeks with the build from 4/30
> to confirm that this problem does NOT happen?

All I still have from that build is the emacs executable, my compiled
sources are from my current build of 6/3.  I can try to occasionally
use the 4/30 executable and monitor its memory usage.  But I should
also continue using the 6/3 build to see if I get a repetition of the
usage I reported, since as I said, it hasn't happened consistently.

Steve Berman

Re: memory usage

[Richard Stallman]

      But I should
    also continue using the 6/3 build to see if I get a repetition of the
    usage I reported, since as I said, it hasn't happened consistently.

How many times has it happened?

Re: memory usage

[Stephen Berman]

On Fri, 15 Jun 2007 15:21:30 -0400 Richard Stallman <rms@gnu.org> wrote:

>       But I should
>     also continue using the 6/3 build to see if I get a repetition of the
>     usage I reported, since as I said, it hasn't happened consistently.
>
> How many times has it happened?

Prior to my post on Monday I didn't notice such a heightened memory
usage, though I cannot swear it didn't occur.  Since the release of
Emacs 22.1 and my latest CVS update a day later I've been alternating
between them.  With 22.1 I haven't experience an inordinate memory
consumption.  On Wednesday with the CVS build the memory consumption
was also not as high as on Monday.  But today I was using the CVS
build again and it used a lot of swap in particular, though resident
memory consumption was less than in my OP; when I killed the session
about half an hour ago, Emacs seemed somewhat sluggish and top
reported this:

 PID %MEM  VIRT SWAP  RES CODE DATA  SHR nFLT nDRT S  PR  NI %CPU COMMAND
 4734 29.3  707m 560m 147m 1476 686m 6932  22k    0 S  16   0  0.0 emacs

Compare this to what I reported on Monday:

  PID %MEM  VIRT SWAP  RES CODE DATA  SHR nFLT nDRT S  PR  NI %CPU COMMAND
 4707 54.5  623m 349m 274m 1476 602m 8336 8928    0 S  17   0  0.0 emacs

Today's CVS Emacs session ran for 14 hours, Monday's ran for 13+
hours, while on Wednesday I had two sessions of about three and a half
and 8+ hours.  I didn't notice whether the memory consumption today
and on Monday started increasing more rapidly after eight or nine
hours.  The next time I'll try to track it more closely.

Steve Berman

Re: memory usage

[Stephen Berman]

I accidentally posted the below in the wrong thread; this is the right
one.

On Mon, 09 Jul 2007 11:06:24 +0200 Stephen Berman <Stephen.Berman@gmx.net> wrote:

> Update: After my last post in this thread on 15 Jun 2007 I continued
> alternating between using the released Emacs 22.1 and the CVS trunk
> builds from 4/30 and 6/3.  The latter continued to show increased
> memory usage, the first two did not show this.  On 19 Jun 2007 Jason
> Rumney <jasonr@gnu.org> wrote in other thread (see
> http://permalink.gmane.org/gmane.emacs.devel/73303):
>
>> There was a brief period where changes in image.c caused a memory leak,
>> and on Windows a GDI resource leak (which caused crashes when the
>> resources allocated reached 9999, after 5-10 minutes of typical use for
>> me). But that was fixed more than a week ago, and was more of a problem
>> on other branches where the fix wasn't merged for until this weekend
>> just gone.
>
> On 6/30 I updated from CVS trunk to my current build, which I've used
> daily since and have not experienced increased memory usage with it.
> So I assume my build from 6/3 had the memory leak, which has since
> been fixed.
>
> Steve Berman