Re: Bug #25608 and the comment-cache branch

[Dmitry Gutov]

Hi Alan,

On 04.02.2017 13:02, Alan Mackenzie wrote:

> I think it would be useful to post the actual patch here, so it can be
> more easily discussed, and to be easier for people who want to try it
> out to get to it.

I'd rather it stays in one place, along with any further revisions, if 
needed. That should cause less confusion in the long run.

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?

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?

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

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.

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