GNU bug report logs -
#78898
Make read/readevalloop reentrant
Previous Next
Full log
Message #86 received at 78898 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Jul 5, 2025, 6:13 AM Mattias Engdegård <mattias.engdegard <at> gmail.com>
wrote:
> 28 juni 2025 kl. 12.08 skrev Eli Zaretskii <eliz <at> 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.
For my next increment, I want to try managing the read stack with alloca
and friends. The way it is now, memory allocated for that stack is never
recovered.
I also tried eliminating base_sp from read0, but it failed. IOW, read0 is
getting recursively invoked in the middle of reading an expression. So the
size of the read stack may not be bounded by the maximum depth of a single
expression. I want to measure what's going on there.
Also, I'd like some concrete cases for measuring the impact of the reader
performance on emacs startup. When I look at the profiles of the dump
recipes, the time spent in lread.c is tiny compared to evaluating the code
being read, even when loading byte-compiled code.
Lynn
[Message part 2 (text/html, inline)]
This bug report was last modified 12 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.