Re: emacs rendering comparisson between emacs23 and emacs26.3

[Stefan Monnier]

> 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.
[ Note: this is just a wild guess on my part.  I never bothered to
  measure it: `syntax-ppss` is a fairly naive implementation with a lot
  of room for improvement.  ]

IOW if it takes the same time as (parse-partial-sexp (point-min) (point-max))
then I'm quite happy ;-)

> How about some other, more common scenarios?

I agree that it's probably not very representative.

>> 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.

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.

> 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.

Yes, the problem is the murky semantics (including the fact that you
can't rely on it being used, even though some code does want to rely on
it, typically in multi-mode setups where it's abused to impose
a boundary).

> 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.

That's also my impression.


        Stefan