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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 13, 2016 at 06:49:53PM -0400, Stefan Monnier wrote:
> > 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.

> There's also the extra cost of applying all those text-properties ....

I've just timed this over xdisp.c.  A parse-partial-sexp from
(point-min) to (point-max) took 0.031s.  A further scan, applying the
`literal-cache' properties, took 0.054s.  That's 0.023s on a 1 MByte
buffer.  That's not too serious.

> .... plus the cost of slowing down application of other
> text-properties (since every time we modify intervals, we have to play
> with the lists of properties of the intervals involved), plus the cost
> of slowing down all lookups of other text-properties.

I imagine the cost of consing over three properties rather than just two
in an interval's plist will be negligible.  The impact of the extra
intervals will also be small.  Heck, we use two whole properties for
font-locking, and nobody notices any slow downs that causes.  One
implementation possibility would be to put `literal-cache' properties on
a distinct interval tree from text properties, thus speeding up both,
but it doesn't seem needed as yet.

> These were some of the reasons which made me choose a separate table for
> syntax-ppss rather than using text-properties.

OK.

> This said, I don't think it matters much.  FWIW, syntax-ppss uses a very
> naive singly-linked list for the simple reason that I decided to "first
> get something working", and I just haven't found a need to go back and
> optimize this data-structure (which could be turned into a tree or even
> an array, in case it mattered).

> Another motivation to go with a separate table was that I figured
> I would then be able to more easily manipulate the cache, e.g. in case
> I wanted to keep several versions of the cache at the same time (e.g. one
> version per syntax-table value being used, or one version per value of
> `point-min').  But there again, I haven't had the need to go back and
> add that kind of functionality yet.

> IOW, I don't think the exact representation chosen matters much.

> What I do think is a pity in your implementation (thinking of it as
> a potential replacement for syntax-ppss) is that it has to do all the
> hard work of computing a full "parse-partial-sexp state" (aka PPSS) and
> then throws away the parenthesis part of the state to only keep the
> string/comment part, making it unable to provide as much info as
> syntax-ppss does, even though it had to work just as hard for it.

Retaining all the information would be much harder and much more
resource intensive.  That why I said the comment-cache implementation is
for a different purpose from syntax-ppss.

syntax-ppss throws away a lot more information that comment-cache does -
it retains a parse state only every 20,000 characters, discarding
everything else between those points.  This makes its cache unsuitable
for using the way I'd like to in back_comment.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).