Re: emacs rendering comparisson between emacs23 and emacs26.3

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Apr 06, 2020 at 17:55:50 +0300, Dmitry Gutov wrote:
> On 06.04.2020 05:36, Richard Stallman wrote:
> > If and when such a mechanism is in place for us free software
> > activists, we might agree that open-paren-in-column-0-is-defun-start
> > is not worth while any more.  But it appears that has not happened
> > yet, so I think that the open-paren-in-column-0-is-defun-start guided
> > heuristic IS still worth while for us.

> This question (whether syntax-ppss is "too slow") was raised a couple of 
> times already, but in all previous discussions, as well as in this one, 
> nobody has done the bare minimum research (e.g. profiling some 
> real-world scenario) to prove this claim. Nor, if it indeed showed up in 
> profiler reports, examined which part of the current mechanism is the 
> bottleneck. Nor tried to fix that part somehow.

> This is not how we should approach performance problems.

> The only arguments I see are nostalgic (e.g., somehow, Emacs was faster 
> years ago, maybe? the files were smaller, and the C standard was simpler?)

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.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).