Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.

[Dmitry Gutov]

On 03/12/2016 11:58 PM, Alan Mackenzie wrote:

> In a large buffer, this involves scanning on average 10,000 characters
> with parse-partial-sexp.  This is not what I meant by "fast".

That severely depends on your usage. Have you tried it?

First, if your calls to syntax-ppss are performed with non-decreasing 
argument (or it decreases rarely), the cache in syntax-ppss-last will 
help a lot.

Second, I'm sure you can decrease syntax-ppss-max-span, if your language 
is expensive to parse.

Third, I *would* call it fast. Examples:

in syntax.el, (parse-partial-sexp 1 10000) takes ~0.0004sec.

in xdisp.c, it takes ~0.0003sec. Probably because it begins with a huge 
comment.

All right, let's get out of that comment:

(parse-partial-sexp 15082 25082) takes ~0.0005sec.

You can try it by evaluating

(benchmark 1 '(parse-partial-sexp 15082 25082))

> What I had in mind looks more like (note the recent renaming of
> `comment-depth' to `literal-cache'):
>
>   (setq lc (get-text-property (point) 'literal-cache))
>   (when (not (equal lc '(0 . 0)))
>     (setq start (previous-single-property-change (point) 'literal-cache))
>     (goto-char start)
>     ;; Move back over opening delimiter(s).
>     )

Yes, it's probably faster on average, by some constant multiplier. But 
it comes with a set of drawbacks that has already been brought up in the 
discussions.

Do you really call this code more than 100 times per user command?

Since the text property approach exchanges memory for performance, 
setting syntax-ppss-max-span to some lower value seems to be the thing 
to try first (yielding a similar effect).