Re: emacs rendering comparisson between emacs23 and emacs26.3

[Dmitry Gutov]

Hi Alan,

On 06.04.2020 22:36, Alan Mackenzie wrote:

> I've attempted to simulate one of Martin's scenarios, and set up my tty
> frame with two side by side windows, each 65 lines deep and wide enough
> for xdisp.c not to need continuation lines.  xdisp.c is displayed in both
> windows, from Line 401 at the LHS, and from Line 35162 on the RHS.  In
> the LH window point is at BOL 435 (the opening brace for function
> fill_column_indicator_column) and in the RH window point is at BOL 35159
> (a random line in start_hourglass).
>
> With various combinations of the pertinent variables, I run
>
>      (time-it (insert "{") (other-window 1) (insert " ") (other-window 1)
>      (sit-for 0))
>
> .  After each such timing I undo the buffer changes before the next
> timing.

So you chose the absolute worst scenario for syntax-ppss, right? Where 
its cache would be unavoidably clobbered at least once. I'm guessing the 
difference between measurements is ~ how long (parse-partial-sexp 
(point-min) (point-max)) takes on your machine in that file.

How about some other, more common scenarios?

Like Martin just scrolling the buffer (we can simulate that with several 
calls to scroll-up).

Or Eli just typing in some large file.

I think these two cases featured more prominently in the recent 
discussions, with associated complaints about performance.

> Here are the results:
>                           open-paren-in-column-zero-is-defun-start
>                               nil                    t
> comment-use-syntax-ppss
>          nil                  0.319s                0.264s
>          t                   0.319s                0.227s
>
> .  Bearing in mind that c-u-s-p being t suppresses the action of
> o-p-i-c-0-i-d-s in back_comment, but not in beginning-of-defun, it seems
> like the o-p-i-c-0-i-d-s mechanism does indeed speed up some scenarios
> in C Mode, significantly but not massively.
>
> IMAO, It would be nice to have the code testing o-p-i-c-0-i-d-s (both
> places) able to ignore spurious cases of parens in literals.

I can't imagine anybody doing the 
type-switch-window-to-the-same-buffer-type routine frequently, but if 
you really want to improve that use case, I think the first takeaway 
that the necessary knobs are still present. A text property check 
wouldn't slow the routines significantly (I think), but you'd have to 
benchmark that as well, and also the extra code in CC Mode which would 
scan the whole buffer and apply those properties. In the first 
implementation, at least, you could do that using the normal 
before/after-change-functions, not "super" ones.

Here's a better idea to try, though: keep comment-use-syntax-ppss set to 
t. And also use syntax-ppss to find the beginning of defun in 
c-beginning-of-defun. But to make it honor the o-p-i-c-0-i-d-s, set 
syntax-begin-function to a new function that contains whatever "fast" 
logic you prefer. E.g. scanning the buffer back for open parens in 
column 1 without certain text property applied. I'm not 100% sure why 
this var is marked obsolete now (probably because it creates murky 
semantics), but this is the simplest way to add this behavior, I think.

In any case, I'm afraid all this won't bring any dramatic improvement in 
the more usual scenarios which I mentioned above. And we'll be back to 
looking for other ways to improve performance.