[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug #25608 and the comment-cache branch

From: Alan Mackenzie
Subject: Re: Bug #25608 and the comment-cache branch
Date: Mon, 6 Feb 2017 19:37:56 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]