GNU bug report logs - #79009
[PATCH] Improve 'vtable' object handling, cache handling, messages

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: Kristoffer Balintona <krisbalintona <at> gmail.com>, Joost Kremers <joostkremers <at> fastmail.fm>, 79009 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>, Adam Porter <adam <at> alphapapa.net>, Lars Ingebrigtsen <larsi <at> gnus.org>, Augusto Stoffel <arstoffel <at> gmail.com>, ijqq <at> protonmail.com
Subject: bug#79009: [PATCH] Improve 'vtable' object handling, cache handling, messages, [PATCH] Improve 'vtable' object handling, cache handling, messages
Date: Tue, 15 Jul 2025 14:57:46 -0400

Stéphane Marks <shipmints <at> gmail.com> writes:

> On Tue, Jul 15, 2025 at 2:07 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
>
>  Stéphane Marks <shipmints <at> gmail.com> writes:
>  > On Tue, Jul 15, 2025 at 10:02 AM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
>  >  Anyway, my patch to vtable--cache follows.  I think we should apply this
>  >  first before your changes, because I believe it's a better approach.
>  >
>  > The patch addresses some of the cache issues but not all of them.  I was planning on addressing cache issues later and
>  starting
>  > with the previous patch to get us going.
>
>  Then you should drop the cache changes from this small patch, since IMO
>  they are wrong, they don't go in the right long-term direction.
>
>  > With regard to the cache, one thing that puzzles me about it, and Lars, if he's reading can chime in, is that the vtable buffer
>  itself
>  > can hold only one formatter representation at a time, munged from cache entries plus formatters/displayers, and if the
>  buffer is
>  > displayed in more than one sized window, it can't hold both widths at the same time.  On table updates, via -insert-object, -
>  > remove-object, -update-object, -revert-command only the "current" cache is updated and the others considered stale.  You
>  can see
>  > in the bigger vtable update I shared, that only one cache entry at a time is rebuilt as needed when the assigned vtable
>  buffer's
>  > window size changes upon selection, and the others considered stale--so why bother with more than one.  So, if we're gonna
>  redo
>  > the cache (and let's assume it's an internal vtable feature that won't impact users if we change it), we should consider doing
>  away
>  > with the multi-width cache and keys and just use the ambient aka most recently-displayed cache entries anyway.  I didn't
>  muck
>  > with the cache further to simplify it assuming Lars had a good reason to implement it that way.
>
>  The sole benefit of the cache is when there are two different
>  windows/frames which are displaying a buffer containing a vtable.  It
>  provides better performance for this case, when the user is repeatedly
>  reverting the vtable in different windows/frames.
>
> The buffer will revert in both windows/frames and be the wrong width
> in one of them, right?

Yes.

> And if they are reverting, the cache isn't useful since the data
> change and the cache is repopulated (for the selected window).  I'm
> missing something.

If the data doesn't change and then you revert the vtable in the other
window, it will be re-rendered faster.

Anyway, I believe this use case is irrelevant and we should simplify the
cache substantially, considering it's a big source of bugs.

Previous Next

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