GNU bug report logs -
#78898
Make read/readevalloop reentrant
Previous Next
Full log
Message #89 received at 78898 <at> debbugs.gnu.org (full text, mbox):
21 juli 2025 kl. 17.29 skrev Lynn Winebarger <owinebar <at> gmail.com>:
> 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.
Not sure why that would be a problem as the stack is usually small. (`alloca` is not without its own problems, especially in Emacs; I prefer not using it.)
> 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.
`read0` must be re-entrant because the \N{CHARNAME} notation makes us call out to Lisp and possibly load some files (for the char names). We could avoid this if it seems likely that it would be worth the trouble.
> 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.
It could be that the reader is already fairly fast (it's seen some improvement lately) but also that profiling isn't easy. If you don't find what you are looking for in a profile it usually means the time is spent elsewhere. In Emacs that is often the allocator and GC but not always.
I'm all for making the reader faster; even small improvements can matter. Complicating things for little or no benefit, not so much. Removing ancient cruft that no longer matters, yes please.
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.