bug#68006: 30.0.50; Image-mode speed

[Eli Zaretskii <eliz@gnu.org>]

> 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.

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.