Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.

[Dmitry Gutov]

Hi Alan,

On 03/14/2016 02:23 PM, Alan Mackenzie wrote:

> > Any performance numbers on using this approach in C/l mode?
>
> [ By "this approach" I'm taking it you mean scanning forward from safe
> positions.]

No, using syntax-ppss's cache. Including the syntax-ppss-last variable.

> No.  Except it uses a lot of parsing forward from safe positions anyway.

IIRC, Stefan posted a patch, which was like 10 lines long.

Could you please try it already, so we can move on to discussing the 
actual performance problems of syntax-ppss, instead of theoretical ones?

> It's two slow to use as a replacement for back_comment, in the sense I
> would like to do - in place of scanning a comment backward character by
> character, I want to use a cache (calculated by forward scanning) to
> determine the beginning of a comment.  Having to scan forward lots of
> characters (as opposed to a few) is out of the question for this
> application.

The approach X is out of the question, because my approach Y is usually 
N times faster!

Why is it out of the question? Can I say "premature optimization"?

> > So I have to wonder why the "get out of a comment" feature is used in
> > C/l mode so much that it becomes a bottleneck, and you get significant
> > improvement in performance by dropping the caching logic to C. That is,
> > of course, not a nice thing to ask considering the overall complexity of
> > CC Mode, but still.
>
> > I don't see anything comparable to 10 second waiting described in
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22884, when doing a
> > comparable operation in a 5000-line Ruby file.
>
> Here's a quick summary of how that happened:  on L1661 of config.h, C
> Mode had to scan back to the beginning of a statement.  That involved
> going back over ~1600 lines of comments and preprocessor constructs.

I went back to the revision a589e9a and rebuilt Emacs. I see the problem 
described in 22884. However, the line 1661 already is a beginning of a 
statement. It contains:

#define _DARWIN_USE_64_BIT_INODE 1

Are we talking about the same file?

> When it got to the critical comment and tried to go back over it,
> (forward-comment -1) said nil, because of that paren in column 0.  That
> paren in column 0, although in a comment, was deemed to be the start of
> a defun.  C Mode was then trying to parse "code" over a region with a
> 1600 line gap in the middle.
> Hence the 10 second delay in seeing the
> character echoed.  Paul has purged our code of parens in column 0.  But
> it would be nice not to have the restriction.

(parse-partial-sexp 1 (point)) on line 1661 takes ~0.002s here.

(parse-partial-sexp 1 (point-max)) takes just a little above that.

How do these timings translate into whole seconds of waiting after 
pressing '/'?

> My point was that it is so simple that it _could_ be written in C, and
> that without any great difficulties.

"It was so simple that I made it more complex"? I mentioned C as a 
drawback, and it is.

> Parts of it can only be written in
> C (the bits that ensure the cache is marked stale when certain
> sytax-table text properties are set/cleared when
> `inhibit-modification-hooks' is bound to non-nil).

These would have to be carefully considered, but if they make sense, 
they would have to be ported to syntax-ppss too somehow.