bug#68006: 30.0.50; Image-mode speed

[Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: stefankangas@gmail.com,  68006@debbugs.gnu.org
>> Date: Mon, 28 Oct 2024 15:31:22 +0100
>> 
>> Here is a new version for my patch to add some user control on the image
>> cache.  This time, I have done some tests and benchmarks.
>> 
>> Instead of trying to have a completely different cache, I'm using the
>> current one but I had a condition to flush (or not) an image based on a
>> user defined time to live (TTL) for an image.  This TTL is a number of
>> seconds since the image was last displayed.
>> 
>> I have also tested it in image-mode with the second patch.  I tested by
>> browsing a directory with some rather large pictures in it (4000x3000
>> pixels, ≈6MB for each file).  I opened the first image in a 1640x1000
>> window (so each image is scaled) and did the following:
>> 
>>   - M-: (dotimes (i 10) (image-next-file 1))  ;; for cache warming
>>   - M-: (dotimes (i 10) (image-next-file -1)) ;; return to first image
>>   - M-: (benchmark-run 10 (dotimes (i 10) (image-next-file 1))
>>                           (dotimes (i 10) (image-next-file -1)))
>> 
>> Here is the timings I get:
>> 
>>      - with master (ea685170063): (109.208767158 15 1.0938777159999997)
>>      - with this patch: (6.934307561 15 1.095243891)
>
> The C part looks OK, but I don't understand how will this be used by
> Lisp programs.  We don't intend to use the new TTL member by default
> each time we display an image, do we?  So I think we need to analyze
> the various uses of images and decide which ones will use TTL (and
> what values to use in that case) and which won't.

Yes I thought that image-mode was a good candidate because I'm typically
using it on directory with lots of images that I'd like to browse (with
'n' and 'p').  But I imagine that this is not a use case for everybody.
In the same idea, I thought that DocView may also be a good candidate.

What I imagined (on the Lisp side) is that a program could load a subset
of images that are close to (in the sense of `image-next-file') the
current one with a TTL set.

> I also envision a need to have a Lisp API which takes an existing
> image and sets its TTL to a given value.  And maybe other APIs as
> well, I don't know.  But without such APIs and without sensible
> defaults about them, this features sounds incomplete.

Yes, sure there is a need for such Lisp API.  I'll try to come up with
something.
-- 
Manuel Giraud