Re: Time to merge scratch/correct-warning-pos into master, perhaps?

[Stefan Monnier]

> I've just tried timing $ make -j17 check on an up to date master, and a
> master two - four weeks old, both configured the same, with native
> compilation.  Much of the run time was taken by native compilation.
>
> The two times were 42.966s and 48.547s.  That's a difference of just
> under 13%.  Not a systematic comparison, since make check may have got
> bigger in the last few weeks.

But that includes compilation time, right?  So that's not the number I'm
worried about.

> And the 1% figure was for a specific timing, namely scrolling through
> xdisp.c from start to end, fontifying as we go.

The 1% I refer to is the goal that Eli set as being acceptable.  I can't
find that email right now, so I'm not sure how specific he was, but to
me it clearly applied to something wider than just that
scrolling benchmark.

>> > When I ran elisp-benchmark on the before and after versions, the change
>> > was 2½% (on a native compiled Emacs).
>
>> So, something changes the cost from 2-3% to 11%.  Maybe it's native
>> compilation (tho I don't know if Gregory ran these with native
>> compilation or not), or maybe it's somewhere in the nature of the code
>> in the test suite, or ...
>
> .... or all of these things.  I suspect it's mainly the increased cost of
> the compilation.

As the person responsible for the patch, I think it's your
responsibility to dig into the report and either "debunk it" or figure
out what is the cause for it, rather than sit back and wave it off as "I
suspect it's <foo>".

>> Mind you, I consider 2½% to be already quite different from "about
>> 1%", ...
> Really?

Speeding up execution by 1% is not super easy, so yes a general slowdown
of 1% is quite different from a general slowdown of 2½%.

>> but I think we should first focus on those 11% reports because I don't
>> think I'm willing to slow down all execution by 10% just to get better
>> position info in the compilation warnings.
> We're not talking about "better" position info.

This is a matter of opinion.  Don't get me wrong, I'm quite happy to
have better positions, but we've lived for many many years with poor
(and even non-existing) position info, and the new info is often
correct, indeed, but (inevitably) not always.

> Compilation has got slower because it's no longer skimping on an
> essential portion of its task.

I am not bothered by the slower compilation.  I'm worried about the
performance impact on execution of code unrelated to compilation.

> You are taking up the emotional element of Gregory's posts.
> There is no "all" in the 10% slow down.

I'd hope you know me better by now.  I do understand that Gregory's
number is just one number, thank you very much.  Please re-read what
I wrote, because AFAIK I have always been very clear about that.
It still remains a worrisome data point.

> But we're not, we're talking about a use case where the computer's
> waiting for the next key stroke nearly all the time anyway.

A lot of Emacs's code falls into this category, yes.  But enough falls
in another category that there's been a lot of enthusiasm over the years
for speeding up execution.


        Stefan