[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 03:13:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 03/13/2016 07:59 PM, Alan Mackenzie wrote:

That severely depends on your usage. Have you tried it?

Have now, yes.

Any performance numbers on using this approach in C/l mode?

Second, I'm sure you can decrease syntax-ppss-max-span, if your language
is expensive to parse.

I would think the speed of parse-partial-sexp is pretty much constant,
independent of the language.

Well, it seems like that you would be calling it much more frequently than other packages. So you could adjust for that.

It will be much faster.  The only looping involved is over the levels of
an optimised binary tree (the text property intervals), not linearly
over 10k characters.  By the time syntax-ppss has finished consing down
its cache list, the text property stuff would be done.

Yes, it would be fast. But like we've noticed, calling syntax-ppss is also quick, and it basically has a constant upper bound, on average. It's hard to be *significantly* faster than that.

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.

But it comes with a set of drawbacks that has already been brought up
in the discussions.

That set has one member: the partial overlap in functionality with
syntax-ppss.  No intrinsic drawbacks have yet been pointed out.  But you
do so below (thanks!).

Aside from everything that's been mentioned already, it's written in C, reducing the pool of developers willing to work on it. And no, it doesn't make it "simple and maintainable", at least from my perspective.

reply via email to

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