GNU bug report logs -
#68006
30.0.50; Image-mode speed
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: stefankangas <at> gmail.com, 68006 <at> debbugs.gnu.org
>> Date: Mon, 21 Oct 2024 12:12:12 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> 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.
Yes, that makes sense.
>> >> 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.
Anyway, here is a patch of what I have done.
Since in the end an image is identify by an ID which is its index in the
images vector, I choose to take this vector out of the cache struct and
put it into what I called an image_store.
Now there are two caches (internal (as before) and user's) that both use
the image_store. In order to make this work, I needed to add a
reference to the cache that manage it in each image.
But, as you said, for just one other field, this code might be
over-engineered and also quite error-prone.
[0001-User-controlled-image-cache.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
--
Manuel Giraud
This bug report was last modified 224 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.