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

Previous Next

Full log

View this message in rfc822 format

From: Stéphane Marks <shipmints <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.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:17:23 -0400

[Message part 1 (text/plain, inline)]

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

But IMO this use case doesn't matter, and I'd be in favor of dropping
> the current cache complexity, if no-one objects.  I suggest using my
> patch as a starting point for that.
>

[Message part 2 (text/html, inline)]

Previous Next

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