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

[Ihor Radchenko <yantar92@gmail.com>]

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

> As I explained elsewhere, unless you call clear-image-cache from Lisp,
> the only place we do that automatically is when the number of
> redisplay cycles since last time the image cache was cleared becomes
> greater than 101.  This, no matter how low is the value of
> image-cache-eviction-delay, it will have no effect until we've done
> 101 redisplay cycles.  And your loop above does just one.

Hmm. I saw that email, but did not understand it well. I thought that
cache clearing is triggered not later than image-cache-eviction-delay,
but can be triggered earlier if the number of cycles is more than 101...

The behaviour you describe does not follow the docstring:
> "*Maximum time* after which images are removed from the cache.
> ...
> If the cache contains
> a large number of images, the actual eviction time may be shorter.
> ...

Also, I repeated my tests manually calling image-clear-cache every Nth
image. Every invocation of image-clear-cache does reduce the memory
consumption, but there is always some residual remaining unrealeased
(see the attached images). The residual seems to scale with the number
of images in the cache before clearing.
Suggestion: we may be able to control the memory consumption if the
image-clear-cache is not only triggered by the time and display cycles,
but also by the cache size. If a variable like image-cache-max-size is
exposed to elisp, the user may be able to deal with similar memory
consumption issues just by reducing the variable value.
Though, indeed, there should be no residual memory in ideal scenario. 

Regards,
Ihor


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

[-- Attachment #3: images-seq-10thclear.png --]
[-- Type: image/png, Size: 22770 bytes --]

[-- Attachment #4: images-seq-50thclear.png --]
[-- Type: image/png, Size: 23355 bytes --]

[-- Attachment #5: images-seq-100thclear.png --]
[-- Type: image/png, Size: 22807 bytes --]

[-- Attachment #6: Type: text/plain, Size: 1542 bytes --]





Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 38345@debbugs.gnu.org
>> Date: Thu, 28 Nov 2019 09:38:34 +0800
>> 
>> #+begin_sec 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))))
>>   (garbage-collect)
>>   (clear-image-cache t))
>> #+end_src
>> 
>> The resulting memory consumption graph is attached.
>> The memory increase almost disappeared (remaining heap size becomes
>> ~40Mb in comparison ~400Mb in the version with just garbage collect).
>> 
>> Just calling (clear-image-cache) after cycling over opening/killing
>> the image buffers still results in ~400Mb (it has no effect, basically).
>> 
>> The above result is confusing since the all the code I tried to run so
>> far had (setq image-cache-eviction-delay 5). Since, cycling over all the
>> images usually took >1min, cache clearing supposed to happen at least
>> several times during opening/killing the image buffers.
>
> As I explained elsewhere, unless you call clear-image-cache from Lisp,
> the only place we do that automatically is when the number of
> redisplay cycles since last time the image cache was cleared becomes
> greater than 101.  This, no matter how low is the value of
> image-cache-eviction-delay, it will have no effect until we've done
> 101 redisplay cycles.  And your loop above does just one.