Weird memory consumption libnked to frame font spec

Weird memory consumption libnked to frame font spec

[Stefan Monnier]

There's something funny with our memory consumption.
Here is a recipe to show the problem, tho it uses mpc.el (and requires
an mpd daemon running), so you may find it rather inconvenient to try
and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
dependency to reproduce the bug, but for now, that's what we have:

- emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l ~/src/elisp/mpc/mpc.el -f mpc

- at this point, you're supposed to be looking at 11 frames, the bottom
  one using the default font to show *scratch*, the 9 middle ones
  showing *scratch* as well but using "Sans", and the top one also using
  "Sans" but showing various windows listing the
  artists&albums&... available in your MPD daemon.
  "ps" should show your Emacs process is largish, but not humongous (in
  my case it's about 60MB).

- Now middle click on some artist in the artist list to select it.
  This should modify most of the buffers in the MPC frame, tho nothing
  really particular: they don't get much longer, they don't use new
  charsets (they may, but at least in my test case they don't), ...
  This is done by sending various commands to the MPD daemon (via one
  TCP connection) and receiving responses in return through the
  process filter.
  Yet, the process size of this running Emacs has jumped up by an
  enormous chunk (to 190MB in my case).

Now you might think "well, now, this mpc.el of yours is doing something
really fishy to eat up so much memory".  But as turns out, If I repeat
this test but passing nil to make-frame rather than (quote ((font
. "Sans"))), the memory use is a bit lower to start with (like 58MB
instead of 60MB) and rather than jump up to 190MB it only slightly
increases to 59MB.  Also the data returned by `garbage-collect' seems to
indicate that most of that memory is not spent on Lisp data.  So the
problem seems linked to the handling of fonts rather than to mpc.el.

Even without this bug, I find that every frame I create causes the
memory size to jump by almost 1MB, which I find rather large but
maybe explainable.  OTOH this jump in size really looks like a bug.


        Stefan

Re: Weird memory consumption libnked to frame font spec

[Kenichi Handa]

In article <jwvocumafgh.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There's something funny with our memory consumption.
> Here is a recipe to show the problem, tho it uses mpc.el (and requires
> an mpd daemon running), so you may find it rather inconvenient to try
> and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
> dependency to reproduce the bug, but for now, that's what we have:

> - emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l ~/src/elisp/mpc/mpc.el -f mpc

Do you see the same memory increase with an actual font
family (e.g. "dejavu sans") instead of such a generic
family name?

---
Kenichi Handa
handa@m17n.org

Re: Weird memory consumption libnked to frame font spec

[Stefan Monnier]

>> There's something funny with our memory consumption.
>> Here is a recipe to show the problem, tho it uses mpc.el (and requires
>> an mpd daemon running), so you may find it rather inconvenient to try
>> and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
>> dependency to reproduce the bug, but for now, that's what we have:

>> - emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l ~/src/elisp/mpc/mpc.el -f mpc

> Do you see the same memory increase with an actual font
> family (e.g. "dejavu sans") instead of such a generic
> family name?

Yes, that makes no difference.


        Stefan

Re: Weird memory consumption libnked to frame font spec

[Kenichi Handa]

In article <jwvskjpzg0x.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> There's something funny with our memory consumption.
>>> Here is a recipe to show the problem, tho it uses mpc.el (and requires
>>> an mpd daemon running), so you may find it rather inconvenient to try
>>> and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
>>> dependency to reproduce the bug, but for now, that's what we have:

>>> - emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l ~/src/elisp/mpc/mpc.el -f mpc

> > Do you see the same memory increase with an actual font
> > family (e.g. "dejavu sans") instead of such a generic
> > family name?

> Yes, that makes no difference.

Ummm, I can't reproduce the case of huge memory increase by
make-frame.  Can't you find a testcase to reproduce it
without your mpc.el?

By the way, I can observe about 1M memory increase, but at
the moment, I don't know where that memory is used.  At
least, font-objects and font-entities are shared by frames.

---
Kenichi Handa
handa@m17n.org

Re: Weird memory consumption libnked to frame font spec

[Stefan Monnier]

> Ummm, I can't reproduce the case of huge memory increase by
> make-frame.

The step that eats up the huge amount of memory does not create any
frame (nor window).  It only communicates with a remote server and
updates a handful of buffers accordingly.

> Can't you find a testcase to reproduce it without your mpc.el?

Still working at it.


        Stefan

Re: Weird memory consumption libnked to frame font spec

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There's something funny with our memory consumption.
> Here is a recipe to show the problem, tho it uses mpc.el (and requires
> an mpd daemon running), so you may find it rather inconvenient to try
> and reproduce it.  Hopefully I'll find a way to get rid of this mpc.el
> dependency to reproduce the bug, but for now, that's what we have:
>
> - emacs -Q --eval '(dotimes (i 10 (other-frame 1)) (make-frame (quote ((font . "Sans")))))' -l ~/src/elisp/mpc/mpc.el -f mpc
>
> - at this point, you're supposed to be looking at 11 frames, the bottom
>   one using the default font to show *scratch*, the 9 middle ones
>   showing *scratch* as well but using "Sans", and the top one also using
>   "Sans" but showing various windows listing the
>   artists&albums&... available in your MPD daemon.
>   "ps" should show your Emacs process is largish, but not humongous (in
>   my case it's about 60MB).

My Emacs process is 28 MiB at this point.

> - Now middle click on some artist in the artist list to select it.
>   This should modify most of the buffers in the MPC frame, tho nothing
>   really particular: they don't get much longer, they don't use new
>   charsets (they may, but at least in my test case they don't), ...
>   This is done by sending various commands to the MPD daemon (via one
>   TCP connection) and receiving responses in return through the
>   process filter.
>   Yet, the process size of this running Emacs has jumped up by an
>   enormous chunk (to 190MB in my case).

Because I didn't set up an album properly, however (I only installed mpc
to try to reproduce this bug), I don't have anything in by artists and
albums windows.  I can, however, click on an entry in the *MPC Songs*
window to play the song.

My Emacs process is still 28 MiB, so I don't see the bug.