Re: emacs rendering comparisson between emacs23 and emacs26.3

[martin rudalics <rudalics@gmx.at>]

 >> I cannot nearly simulate the problem using a simple loop that steadily
 >> invokes say (forward-line 50) followed by a (sit-for 0).  50 such
 >> invocations take 16.7 seconds here, 22.7 with (forward-line -50).  And
 >> redisplay takes place as expected here.  So it's likely the mouse wheel
 >> input mounting up that inhibits redisplay.
 >
 > Not forward-line, scroll-up.  That's what wheel.el calls.

I know.  But I wanted to not relate the behavior to things like the
window configuration.

 >> Do you at least see CPU activity significantly go up when you do such
 >> mouse wheel scrolling?
 >
 > With what build?  With the -O0 build with --enable-checking, I don't
 > need the mouse: it's enough to lean on C-v and let the keyboard
 > auto-repeat do its job -- one execution unit of the CPU maxes out
 > after 5 to 10 C-v's.

OK.  Then people see the problem and it's just that they do not build
with -O0.

 > But with a -O2 optimized production build, Emacs keeps up both when I
 > lean on C-v and when I turn the mouse wheel constantly.

Same here.

 > Anyway, you don't need to work too hard to get me started on how slow
 > CC Mode is, especially when re-indentation is involved in addition to
 > font-lock.  Which is why I think we should move away of regexp-based
 > and SMIE-based engines towards fast parsers written in C.

As long as we are not there (and IMO even after that) Emacs should be
able to do its SMIE parsing in a practical way: Restrict backward and
forward parsing to the smallest reasonable code fragment around point.
And reasonable would mean the smallest enclosing fragment delimited by
two parens in column zero it can find in either direction (which can be
still quite large when viewing functions like redisplay_internal).

martin