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

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Mar 13, 2016 at 12:16:38AM +0200, Dmitry Gutov wrote:
> 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?

Have now, yes.

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

OK, I'd overlooked that.

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

I would think the speed of parse-partial-sexp is pretty much constant,
independent of the language.

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

[ .... ]

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

OK.

[ .... ]

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

It will be much faster.  The only looping involved is over the levels of
an optimised binary tree (the text property intervals), not linearly
over 10k characters.  By the time syntax-ppss has finished consing down
its cache list, the text property stuff would be done.

> But it comes with a set of drawbacks that has already been brought up
> in the discussions.

That set has one member: the partial overlap in functionality with
syntax-ppss.  No intrinsic drawbacks have yet been pointed out.  But you
do so below (thanks!).

> Since the text property approach exchanges memory for performance, 

I've counted the intervals on xdisp.c.  Fully fontified, xdisp on master,
there are 55274 intervals with ~442192 conses (That's estimating 2
conses per symbol/property pair on the interval's plist).

In branch comment-cache, on a fully fontified, and fully cached xdisp.c
buffer, there are 55786 intervals with ~557860 conses, that's an extra
512 intervals, or less than 1%.  There are an extra ~115668 conses,
about an extra 25%.  I'll admit this is a drawback.

-- 
Alan Mackenzie (Nuremberg, Germany).