bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs)

[Ihor Radchenko]

> Does it help to call garbage-collect after killing each buffer and
> before visiting the next image file?

No. It makes no difference.

> I don't understand the question, sorry.  GC in Emacs is implemented in
> C, not in Lisp.  If you mean to use a garbage-collecting memory
> allocator, then we once had that only for buffer text, but nowadays
> system malloc is good enough for that, so we no longer use it.  Doing
> that for "normal" C code is not easy because it generally requires
> double indirection for accessing data through pointers.

Yes, I meant garbage collecting malloc. I don't know much about this
topic. Just stumbled on an article saying that it can speed up
performance.

Regards,
Ihor


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@gmail.com>
>> Cc: 38345@debbugs.gnu.org
>> Date: Tue, 26 Nov 2019 23:21:11 +0800
>> 
>> 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.
>
> Does it help to call garbage-collect after killing each buffer and
> before visiting the next image file?
>
>> P.S. Were there any attempts to implement garbage collection for emacs
>> in C code?
>
> I don't understand the question, sorry.  GC in Emacs is implemented in
> C, not in Lisp.  If you mean to use a garbage-collecting memory
> allocator, then we once had that only for buffer text, but nowadays
> system malloc is good enough for that, so we no longer use it.  Doing
> that for "normal" C code is not easy because it generally requires
> double indirection for accessing data through pointers.