Re: emacs rendering comparisson between emacs23 and emacs26.3

[Dmitry Gutov]

On 07.04.2020 02:41, Stefan Monnier wrote:
> > 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.
>
> FWIW, `syntax-ppss` has not been optimized for this case at all, so
> I wouldn't be surprised if it takes noticeably more than
>
>      (parse-partial-sexp (point-min) (point-max))
>
> because it performs that computation in chunks, and the overhead for
> each chunk is likely non-negligible.

The times it takes here, in an optimized build, fluctuates from 0.02 to 
0.05. So indeed, the difference is larger. But the same order of 
magnitude, which is still pretty good, IMO.

> > > 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.
>
> The problem here is that in order to decide whether or not it's *still*
> spurious after the change near BOB, you basically have to compute the
> equivalent of `syntax-ppss`.  So we're back to square one.

That's a good point. In this particular scenario all column-1 parens 
down in the buffer should be invalidated.

> What could be done is to change `syntax-ppss` so it optimizes for the
> case where the buffer changes do not impact the way parsing is done
> "further down" (i.e. not for the case where the change just opened (or
> closed) a string/comment).  Not sure it's worth the trouble, OTOH.

Yup. Not sure either, but let's see what feedback others give.

Or we could try indefinitely supporting the "worse-is-better" semantics 
offered by o-p-i-c-0-i-d-s if, again, it's really in demand.