[Top][All Lists]

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

Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.
Date: Mon, 14 Mar 2016 18:15:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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

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

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.

reply via email to

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