Re: Bug #25608 and the comment-cache branch

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Feb 06, 2017 at 03:28:44 +0200, Dmitry Gutov wrote:
> Hi Alan,

> On 04.02.2017 13:02, Alan Mackenzie wrote:

[ .... ]

> For any casual observers in this discussion who don't want to follow the 
> links: the patch touches src/syntax.c, and it's 20 lines long.

> > syntax-ppss being too slow was its use in a specific circumstance.  That
> > was trying to use it in place of comment-cache's cache mechanism, but
> > otherwise using comment-cache.  That would result in ~2 orders of
> > magnitude slowdown in backward_comment.

> Ah, so that's what you were arguing against?

Yes.  I thought at the time that that's what you were advocating.

> Does comment-cache code contain some other functionality that we'd want 
> to retain while using the syntax-ppss cache? Something that makes 
> performance overhead of syntax-ppss a problem still?

There's the failure to clear the syntax-ppss cache (e.g. after applying
syntax table properties) that I outlined in detail in my other post.
comment-cache's cache is cleared correctly in these circumstances.

> >>> The "alternative patch" didn't scan comments correctly all the time
> >>> when I looked at it, just as the current back_comment doesn't.

> >> Please remind us of the specific problems it has.

> > In the following test case (same as in my other post) the "alternative
> > patch" doesn't work.  Narrow the buffer with point-min at the indicated
> > position.  Put point at EOL.  Try M-: (forward-comment -1).  This fails.

> >      char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /*  */  /*   '"'"  */
> >                        ^

> > .

> Thank you for the reminder. But do you have any examples that do not 
> involve narrowing?

No (other than cache clearing problems).  The bug on a narrowed buffer
is serious enough not to require "support" from other bugs.

> Reconciling syntax-ppss with narrowing is a subject of a separate thread 
> (one that's regrettably stalled for a while, but I'll get back to it 
> soon). As soon as it's resolved, the Alternative Patch should not have 
> this problem anymore either.

Not this one, no.

> > Using M;- (time-scroll) from the start of xdisp.c, and (time-scroll t)
> > from its end (having cleared caches by typing a character at BOB), I get
> > these timings

> >                        forward              backward
> > master                 34.51s               36.43s
> > comment-cache          33.68s               32.81s
> > "alternative patch"    35.49s               36.05s

> Thanks!

> > It would seem that differences in speed are not big enough to make any
> > decision on that basis.

> Does that just leave the narrowing issues, or is there something else?

See above and my other post from this evening for the "something else".

-- 
Alan Mackenzie (Nuremberg, Germany).