On Sat, Jul 5, 2025 at 6:13 AM Mattias Engdegård
<mattias.engdegard@gmail.com> wrote:
>
> 28 juni 2025 kl. 12.08 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > Do we really want readevalloop be recursive this way?  What does this
> > gain us?
>
> In principle there should be no reason for readevalloop being non-reentrant at all and remedying this should be an obvious improvement, but I cannot give a concrete example of how it would benefit us immediately.
>
> That said, I think the approach here is a bit too much at once; I'd rather nibble away at state a little at a time since much of lread.c is messy legacy code.
>
> More to the point, I have a patch for lread.c which cleans up some poor code, fixes some bugs and most importantly improves reader performance. I'd rather that go in first, as it provides tangible improvements and so that I won't have to undo Lynn's changes when applying it. (Further work in bug#70988).

Hi, Mattias,
I'm not sure which version of the patch you're referring to.  The last
one removed a number of changes not necessary for re-entrancy.
One thing all of the versions did was address the initial issue in bug
#70988 by making the "multibyte" decision about the input of any given
entry to the users of "READCHAR/UNREAD" only at entry or when it could
be changed by an intervening "eval".  Instead of having a single
version of readchar, there are different versions for each combination
of input type and multibyte-ness that are straight-line code.  The
correct version is chosen at initial entry or when restoring the state
of any entry point after an eval.  I do still have two outstanding
test failures from make check.  I haven't tried the check-expensive or
check-all targets.

Do you have benchmarks I can use for concrete speed measurements?  I
haven't noticed any particular slow-down with my version, and it's
compiled without native-compile so it should be using the reader
pretty heavily.  That said, I'm using a -O0 build, so an optimized
build might make more efficient use of statically allocated variables.

I'm attaching the last version of my patch.  It should be contained in
the bug record already, but I don't know how convenient or
inconvenient that is.  It's still a non-trivial patch.

Lynn