On Sat, Jul 5, 2025, 6:13 AM Mattias Engdegård wrote: > 28 juni 2025 kl. 12.08 skrev Eli Zaretskii : > > > 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