[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: Thu, 17 Mar 2016 02:47:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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

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.

reply via email to

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