emacs-devel
[Top][All Lists]
Advanced

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

Re: Permission requested to merge branch comment-cache into master.


From: Alan Mackenzie
Subject: Re: Permission requested to merge branch comment-cache into master.
Date: Sat, 12 Mar 2016 23:17:13 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, John.

On Sat, Mar 12, 2016 at 01:38:54PM -0800, John Wiegley wrote:
> >>>>> Eli Zaretskii <address@hidden> writes:

> > Then I think this should go to the release branch. If there's a way to test
> > it better on a branch, fine. Otherwise, let's include it in the next
> > pretest, and let the crowd find any problems it could still have.

> This change may be ready for 25.2 at a future date, but I don't believe it's
> ready now.

I would say it's not quite ready, but it's not far off.

> Also, there is still enough debate around this feature from others, that I
> prefer it to incubate on a feature branch at this time.

That's where it is, on branch comment-cache.  But it would be nicer to
hear "actively test" than "incubate".  ;-)

> Especially, I'd like to see if there's a way to integrate your efforts
> with Stefan's, rather than developing two separate systems to address
> similar ideas.

This is not possible, and the suggestion that it is is mischievous.  The
two approaches are fundamentally different.  They aim to do different
things, and they do them in very different ways.

The comment-cache code is designed optimally to handle comments and
strings and those things only, and to handle them at lightening speed.
It is also written with simplicity and maintainability in mind.
`syntax-ppss' is more general, handling general parse states, and does
so with less speed.  There is absolutely no reason why these two systems
cannot exist at the same time.  Indeed, they should.

`syntax-ppss' is broken (see bug #22983): it does not do what its
specification says, and what its specification says is unsuitable for
use in the low level syntax routines.  It is possible a similar function
may be developed to take the place of `syntax-ppss' sometime in the
future, but this will need development and testing, and around 200 calls
to it in the Emacs sources will need checking and possibly adaptating.

By contrast, the code in the comment-cache branch is ready now and,
modulo minor bugs, is working.  There has been no intimation from
anybody that it doesn't work.  It would be a shame for it to languish
unused on a feature branch.

You mentioned in another post that you were concerned about the speed of
CC Mode.  Well, I have prepared an emacs-25 build and a comment-cache
build, strictly comparable, and timed Martin Rudalics's two functions
`foo' and `bar' on xdisp.c.  `foo' repeatedly calls `end-of-defun',
`bar' repeatedly calls `beginning-of-defun'.  Here are the timings:

             emacs-25            comment-cache       increase in speed
foo            2.590                 1.662                56%
bar            2.981                 1.628                83%

Thus on this (admittedly limited) test, comment-cache has delivered a
massive speed boost to CC Mode, something I hadn't expected.  There is
more speed to be wrung out of the comment-cache mechanism - where now
there is much scanning forward from "safe positions" (i.e. positions not
in comments and strings), in comment-cache this could be rendered
unnecessary, since the nearest safe position is no further away than a
couple of text property lookups.

By contrast, `syntax-ppss' works by keeping a list of positions 20,000
characters apart, and scanning forward from these position to produce
the parse state at the desired position.  This cannot compete speedwise
with comment-cache.

Where, then, do we go from here?  Just how important is CC Mode's lack
of performance?

> Thanks,
> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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