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

[Dmitry Gutov]

On 03/14/2016 11:20 PM, Alan Mackenzie wrote:

> I meant, its deficiencies need fixing, and it's not clear at this stage
> how that's to be done.  I've said elsewhere what I expect to happen:
> that it will be superseded by a different function with the same name.

And I've replied to it already. The "deficiencies" aren't fixed yet 
because they haven't bothered anyone enough yet. The narrowing thing is 
relatively minor, compared e.g. to bug#23019 you've filed recently. 
Fixing that one would at least change the "internal data" of 
parse-partial-sexp.

> > Apparently, the point is that you've been offered a simpler solution for
> > the same problem, and that you basically ignored it.
>
> The simpler solution is a solution to a subset of the problem, more of a
> workaround than a solution in my view, as I've already said.

It does fix #22884 as described, though. I've checked.

> > [...] you'd first have to let me know what to test.
>
> Working out what to test is the time consuming bit.

The reproducible test case is a normal part of a patch submission, in 
the absence of a prior bug report. A patch looking for a problem would 
be silly.

> > If the comment cache patch doesn't actually help with 22884, why are
> > we even discussing it?
>
> Because it solves the problem which was the ultimate cause of bug
> #22884.

And yet it doesn't solve 22884? How odd.

> > Ah, so the speed advantage of using text properties is not that much of
> > advantage. Correct?
>
> It's currently unknown.  That's one reason I'd like to get it merged
> with master, so as people could try it out.  As already discussed, on
> certain restricted tests it's significantly faster.

Why don't we just collect the actual cases where CC Mode is slow, and 
test improvements against those? Instead of pushing changes to master 
and using the early adopters as one big distributed testing facility.

I mean, anticipating unknown problems sounds nice, but it's hardly the 
most important thing, given we have plenty of known ones.

> > Can you produce a test case where it fails? This time without involving
> > narrowing, please.
>
> Of course not.  The code is twisted, with lots of special cases,
> exceptions, and so on.  It even notes in its comments certain corner
> cases which won't work.  It will fail again.

High-level Lisp and abstractions are hard, let's write everything in 
assembly. Then it'll surely never fail.

If the code is as unreliable as you say, producing a problem case should 
be trivial.

> Anyhow, when you're testing something like this, what's the point of
> only testing with nice easy cases?  The code must work correctly with or
> without narrowing.

In other words, you can't give a single problem example which wouldn't 
involve narrowing? And which *would* work with text property-base cache.

> It's slightly more impressive than a 60% decrease in performance.  Note
> that the test wasn't specially written to exhibit high performance (like
> some "benchmark" tests are arranged to do).

If someone provides an arbitrary piece Lisp code, and a patch which 
speeds up it execution by say 100%, the usefulness of the patch can 
still be questioned if the code is never a hot spot in practice.