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

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Mon, Mar 14, 2016 at 03:13:43AM +0200, Dmitry Gutov wrote:
> 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?

[ By "this approach" I'm taking it you mean scanning forward from safe
positions.]

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

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

Maybe.

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

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.

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

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

My point was that it is so simple that it _could_ be written in C, and
that without any great difficulties.  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).

-- 
Alan Mackenzie (Nuremberg, Germany).