Re: The current state of the comment-cache branch

[Alan Mackenzie]

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.

> 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.  Instead comments and strings will be
scanned only in the forward direction, the results of these scan
operations being cached in a text property.  `back_comment' in syntax.c
will be superseded by a new implementation which uses these text
properties, and various other parts of Emacs will be amended to ensure
these text properties stay consistent with the buffer and the current
syntax table.  All of this is implemented in the comment-cache branch,
and completely removes the cause of all of these paren bugs.

o-p-i-c-0-i-d-s would then have a role only in lisp.el in
`beginning-of-defun-raw'.

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

> Thanks.

> P.S. What does "hwm" stand for in literal-cache-hwm?

As Paul suggested, "high water mark".  It is perhaps not a very good
name and could be changed.  The allusion is to the highest point on a
beach reached by the sea at high tide.  This is marked as a line on some
(English) maps under the abbreviation HWMOT, "high water mark, ordinary
tide".

-- 
Alan Mackenzie (Nuremberg, Germany).