Re: bug#20352: Factor 2 slow down of font-locking in c-mode

Re: bug#20352: Factor 2 slow down of font-locking in c-mode

[Alan Mackenzie]

Hello, Stefan.

On Sat, Apr 18, 2015 at 10:02:17AM -0400, Stefan Monnier wrote:

> Hmm... I hope comparing the profiler reports will give us a clue.

Indeed.  Some while ago, you were musing on putting syntax-ppss, or
equivalent, into syntax.c, thus rendering
open-paren-in-column-0-is-defun-start unnecessary and obsolete.  This
would speed up or improve the accuracy of, in particular, back_comment
and the stacks of things which depend upon it.

Is this enhancement still intended?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug#20352: Factor 2 slow down of font-locking in c-mode

[Stefan Monnier]

> Indeed.  Some while ago, you were musing on putting syntax-ppss, or
> equivalent, into syntax.c, thus rendering
> open-paren-in-column-0-is-defun-start unnecessary and obsolete.  This
> would speed up or improve the accuracy of, in particular, back_comment
> and the stacks of things which depend upon it.

> Is this enhancement still intended?

Not in the short term, no.  I've toyed with it, but there's a problem:
syntax-ppss's caching relies on the syntax-table being constant.
This usually works fine because the callers "know" to call syntax-ppss
outside of with-syntax-table (I guess in reality they don't really know,
but they happen to do that because they call syntax-ppss fairly early
on), but it's not uncommon for Elisp code (definitely including CC-mode)
to use with-syntax-table around calls to forward-sexp/comment, so
calling syntax-ppss implicitly from within those functions exposes this
underlying syntax-ppss limitation.

IOW, it can't be done until we figure out how to make syntax-ppss handle
syntax-table changes.


        Stefan

Re: bug#20352: Factor 2 slow down of font-locking in c-mode

[Alan Mackenzie]

Hello, Stefan.

On Sun, May 03, 2015 at 10:13:48PM -0400, Stefan Monnier wrote:
> > Indeed.  Some while ago, you were musing on putting syntax-ppss, or
> > equivalent, into syntax.c, thus rendering
> > open-paren-in-column-0-is-defun-start unnecessary and obsolete.  This
> > would speed up or improve the accuracy of, in particular, back_comment
> > and the stacks of things which depend upon it.

> > Is this enhancement still intended?

> Not in the short term, no.  I've toyed with it, but there's a problem:
> syntax-ppss's caching relies on the syntax-table being constant.
> This usually works fine because the callers "know" to call syntax-ppss
> outside of with-syntax-table (I guess in reality they don't really know,
> but they happen to do that because they call syntax-ppss fairly early
> on), but it's not uncommon for Elisp code (definitely including CC-mode)
> to use with-syntax-table around calls to forward-sexp/comment, so
> calling syntax-ppss implicitly from within those functions exposes this
> underlying syntax-ppss limitation.

Ah.  That sounds like a shame.

> IOW, it can't be done until we figure out how to make syntax-ppss handle
> syntax-table changes.

How about having an association list of ((syntax-table . cache) ...), or
something like that?  Each cache would need its own value of the
equivalent of `syntax-propertize--done'.  `modify-syntax-entry' would
need to wipe the cache.  Then there are `category' text
properties/overlays which might affect the syntax.  And so on.  And so
on.

OK.  It's difficult.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).