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: Stefan Kangas <stefankangas <at> gmail.com>
Cc: manuel <at> ledu-giraud.fr, 68006 <at> debbugs.gnu.org
Subject: bug#68006: 30.0.50; Image-mode speed
Date: Tue, 02 Jan 2024 14:49:12 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 1 Jan 2024 16:19:31 -0800
> Cc: manuel <at> ledu-giraud.fr, 68006 <at> debbugs.gnu.org
> 
>     > The real purpose of the image cache is not to hold the image in
>     > memory for displaying it again and again, the purpose is to allow
>     > the display engine to generate the pixels once, then reuse those
>     > pixels during the current redisplay cycle or a few following
>     > redisplay cycles.
> 
> Basically, I don't see how this difference relates to manually evicting
> the cache or not.

My point was that you are expecting from this cache something that it
wasn't intended to provide.  As a corollary, I think if we want to
speed up paging through images, we should design and implement a
separate cache, which is designed to support the use case of going
through many images one by one, back and forth.

> > In a nutshell, this cache is ephemeral anyway, and will be flushed at
> > some arbitrary time whether we want it or not, because its purpose is
> > not what you think it is.
> 
> If it is flushed anyways, then that is exactly what we want here, I
> think.  The idea is to flush it less often, AFAIU.

My point is that you cannot currently control when it is flushed, not
fully anyway.  Again, the reason is that the cache was not for the
purpose we need caching images in the case that's being discussed
here.

> > In any case, if you intend to not flush the cache at all, then what
> > does that mean for Emacs sessions running for days and weeks, let
> > alone months, on end? will they keep these images in memory forever?
> > Or should GC sometimes evict those images from the cache, and if so,
> > under what conditions?
> 
> Are you saying that, if this particular call is removed, we will never
> flush the cache

Not just this call: you'd need to remove or disable the code which
evicts images from the cache "when the display engine feels like it".
And if you do that, then yes, the images will never be flushed, since
there will be nothing the flushes the cache.

> (i.e. we will have memory leaks)?

Not a memory leak, but memory that is never released.

Basically, we lack a good way of knowing that a given cached image is
no longer needed.  The cache as it exists now doesn't care, since it
isn't supposed to hold the image long enough for that to matter; but
if you want a tighter control on when an image is uncached, we need to
design and implement a way for that, and the main stumbling block in
that case is how to define conditions under which an image can be
evicted from the cache.

Previous Next

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