Re: The current state of the comment-cache branch

[Eli Zaretskii]

> Date: Tue, 27 Dec 2016 16:40:18 +0000
> Cc: address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> Hello, Eli.
> 
> On Sat, Dec 24, 2016 at 02:27:26PM +0200, Eli Zaretskii wrote:
> > > Date: Sat, 24 Dec 2016 09:42:46 +0000
> > > From: Alan Mackenzie <address@hidden>
> > > Cc: address@hidden
> 
> > > > Can you show similar timings with that variable set to nil?  And in
> > > > particular in the use case reported by Paul back when bug#22884 was
> > > > filed?
> 
> > > master:                        101.939s            95.049s        103.546s
> > > (with open-paren-... nil)
> 
> > Hmm... doesn't match my timings here.
> 
> > With an optimized (-Og) build of Emacs 25.1.90, I get 42.844 with
> > open-paren-in-column-0-is-defun-start t and 62.234 nil.  With the
> > unoptimized build of the current master, I get 193.922 and 1117.469,
> > respectively.  The 193 sec result is marginally reasonable for an
> > unoptimized build, the 1117 sec result is IMO preposterous, and the
> > 6-fold slowdown is IMO too much to be explained just by the variable.
> 
> If the buffer is large enough (were you using xdisp.c?) a large factor
> slowdown from using o-p-i-c-0-i-d-s seems inevitable.

I was using the same file xdisp.c and the same timing code as you.
That's why I don't understand how come our results are so different.
With such differences unexplained, how can we ever trust these
benchmarks?

> > Anyway, is your suggestion to adopt the code on that branch and set
> > open-paren-in-column-0-is-defun-start to nil?  If we are not going to
> > set it to nil, then the speed advantage is IMO too small to justify
> > the changes.
> 
> No.  My suggestion is that open-paren-in-column-0-is-defun start ceases
> to play any role in syntax.c.

Does that mean to effectively set it to nil?  Otherwise, I don't
understand how can we judge the current situation vs what you suggest.

> Instead comments and strings will be scanned only in the forward
> direction, the results of these scan operations being cached in a
> text property.

Btw, adding text properties slows down redisplay.  I don't think the
slow-down is significant, but it's worth having in mind anyway.

> > Also, I wonder why do we need all these changes in syntax.c, when the
> > problem is AFAIK only with C mode and its derivatives.  Are these
> > changes beneficial in any way to modes with non-C syntax?
> 
> The changes are in syntax.c because this is where the fundamental cause
> of the problem lies.  I don't believe it is possible to solve them in CC
> Mode.  I don't know why the problem doesn't manifest itself in other
> modes.  Perhaps other modes do less scanning of comments backwards (with
> `scan-sexps' with a negative count).

If we don't completely understand the problem, and cannot explain why
it happens only in CC mode, then how do we make sure we solve the
problem which needs to be solved?  Why would the amount of
back-scanning through comments depend on the major mode?  I don't
think that C programmers write more/longer comments than programmers
in any other programming language.