unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 38345@debbugs.gnu.org
Subject: bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs)
Date: Tue, 26 Nov 2019 23:21:11 +0800	[thread overview]
Message-ID: <87lfs2mzo8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <83o8x0rl6d.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]

Thanks for the links. I got to know more about memory management now.
Now, it is clear why the memory is consumption is so high when I open a
bunch of images at the same time. However, it still does not explain my
observations during usual workflow.

For my real usage, I open pdfs (or images) one by one most of the time
and kill the buffers periodically.
Then, if the memory is freed upon closing a pdf buffer, I expect it to
be reused for opening a new buffer. Even though memory consumption is
expected to grow in this case, it should be in order of the largest
image I open (times maximum number of image buffers open at the same
time). But it is not what I see.

I did a small test by modifying my earlier lisp code to open and close
the same image list sequentially:

#+begin_src emacs-lisp
(dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
  (find-file file)
  (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list)))))
#+end_src

The resulting memory usage graph is attached.

What we can see is that the memory is indeed growing (as expected).
Moreover, the memory consumption does not increase as much as if we open
all the images together. However, the final heap size appears to be over
400Mb (from smaps), which is almost half of what was observed with all
the images open at the same time. Since the largest .jpg file I have in
the folder is just around 5.5Mb, 400Mb sounds strange for me. Googling
on memory consumption issues, I found that there might be some memory
fragmentation problem happening [1].

P.S. Were there any attempts to implement garbage collection for emacs
in C code? I found an article [2] showing that using an actual GC may speed
up an application in comparison with malloc/free approach. 


[1] https://stackoverflow.com/a/9069474/9196985
[2] https://www.linuxjournal.com/article/6679

Regards,
Ihor


[-- Attachment #2: images-seq.png --]
[-- Type: image/png, Size: 22275 bytes --]

[-- Attachment #3: Type: text/plain, Size: 626 bytes --]



Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@gmail.com>
>> Date: Sat, 23 Nov 2019 22:37:44 +0800
>> 
>> If I open a large (>250) photos using the code below, the memory usage
>> increases permanently even after I close all the image buffers and wait
>> for some time. 
>
> For some background on this, see
>
>   https://unix.stackexchange.com/questions/53447/does-free-unmap-the-memory-of-a-process
>   https://stackoverflow.com/questions/1421491/does-calling-free-or-delete-ever-release-memory-back-to-the-system
>
> I think what you see is just normal behavior of memory allocation in
> glibc.


  reply	other threads:[~2019-11-26 15:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23 14:37 bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Ihor Radchenko
     [not found] ` <handler.38345.B.15745199896049.ack@debbugs.gnu.org>
2019-11-23 14:44   ` bug#38345: Acknowledgement (27.0.50; Permanent increase in memory consumption after opening images (or pdfs)) Ihor Radchenko
2019-11-23 14:48 ` bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Lars Ingebrigtsen
2019-11-23 15:12   ` Ihor Radchenko
2019-11-23 14:50 ` Eli Zaretskii
2019-11-23 15:18   ` Ihor Radchenko
2019-11-23 15:45     ` Eli Zaretskii
2019-11-23 16:04       ` Ihor Radchenko
2019-11-23 16:34         ` Eli Zaretskii
2019-11-23 17:33           ` Ihor Radchenko
2019-11-23 17:51             ` Eli Zaretskii
2019-11-25 16:10 ` Eli Zaretskii
2019-11-26 15:21   ` Ihor Radchenko [this message]
2019-11-26 15:55     ` Eli Zaretskii
2019-11-26 16:24       ` Ihor Radchenko
2019-11-27 21:17     ` Juri Linkov
2019-11-28  1:38       ` Ihor Radchenko
2019-11-28 12:35         ` Lars Ingebrigtsen
2019-11-28 13:11           ` Ihor Radchenko
2019-11-28 15:10         ` Eli Zaretskii
2019-11-28 17:27           ` Ihor Radchenko
2019-11-28 18:44             ` Eli Zaretskii
2019-12-02  8:04               ` Ihor Radchenko
2019-12-02 15:49                 ` Eli Zaretskii
2019-12-05  6:48                   ` Ihor Radchenko
2019-12-05 14:52                     ` Eli Zaretskii
2019-12-06  1:34                       ` Noam Postavsky
2019-12-06  7:52                         ` Eli Zaretskii
2019-12-07 19:25                           ` Noam Postavsky
2019-12-07 19:39                             ` Eli Zaretskii
2019-12-16  6:18                       ` Ihor Radchenko
2019-12-16 16:30                         ` Eli Zaretskii
2020-08-02 18:14                           ` Lars Ingebrigtsen
2020-08-02 22:52                             ` Ihor Radchenko
2020-08-03  6:10                               ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lfs2mzo8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me \
    --to=yantar92@gmail.com \
    --cc=38345@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).