GNU bug report logs - #68006
30.0.50; Image-mode speed

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: stefankangas <at> gmail.com, 68006 <at> debbugs.gnu.org
Subject: bug#68006: 30.0.50; Image-mode speed
Date: Sat, 19 Oct 2024 12:34:04 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: stefankangas <at> gmail.com,  68006 <at> debbugs.gnu.org
> Date: Thu, 17 Oct 2024 11:51:08 +0200
> 
> I'm trying to revisit this idea of having a user controlled image cache.
> The goal is to have, for instance, image-mode use it because (hopefully)
> it would have a better idea of when to cache/uncache images for its
> usage.
> 
> Here is a patch of such a prototype « user image cache ».
> 
> 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.

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

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.