Subject: Re: bug#68006: 30.0.50; Image-mode speed

From: Eli Zaretskii <[email-masked]>
Date: Mon, 21 Oct 2024 13:33:38 +0300

> From: Manuel Giraud <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Mon, 21 Oct 2024 12:12:12 +0200
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> [...]
> 
> >> For the moment, I wanted to keep it minimal so the only interface to use
> >> it goes as follow.  When a user (or a program) use the image attribute
> >> ":ttl TIME_IN_SECONDS" with `create-image' such image will be stored in
> >> the « user cache » and not in the internal one.  Images lookups use both
> >> caches (internal and internal, in that order).  A negative
> >> TIME_IN_SECONDS means « cache this image forever ».
> >
> > Why do we need a separate cache for this? couldn't we instead just add
> > the EOL field to the single cache we already have?  having two caches
> > requires to search both of them, which slows down image look up, so if
> > we can avoid that, it's better.
> 
> That's you (in this thread) that suggested having another cache for more
> "user controlled" usage and suggested that lookup_image could search in
> both caches.

I said that assuming the difference will be more prominent than just
one field.

The implementation could be a single cache with a field or fields that
distinguish between the two kinds of cached images.

> >> I think there will be a need for user function that completely flushes
> >> the images in this new cache.  But do you think we need others commands
> >> for such interface?
> >
> > We probably need a way for modifying the time an image is to be kept,
> > at least.
> 
> Yes.  Anyway, my last patch was completely wrong and I am working on
> another one.  Tell me if you're interested to see where I'm headed to.

It's your call.  I and others are here to provide feedback if you feel
you need that.