[Top][All Lists]

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

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

From: Alan Mackenzie
Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps?
Date: Sat, 22 Jan 2022 22:55:44 +0000

Hello, Gregory.

On Sat, Jan 22, 2022 at 22:36:11 +0000, Gregory Heytings wrote:

> >>> That's consistent with what was reported at the beginning of this 
> >>> thread (~7% slowdown).  Byte compilation is expected to be slightly 
> >>> slower with this change.

> >> But make check does a lot more than byte compilation, or am I missing 
> >> something?

> > Not much more, IME.

> That's not what the numbers tell us (again 3b33a14380 vs 7922131bb2):

> make -j1 check: 181s (69s byte-compilation, 112s execution) vs 162s (58s 
> byte-compilation, 104s execution)
> make -j4 check: 45s (17s byte-compilation, 28s execution) vs 40s (15s 
> byte-compilation, 25s execution)
> make -j8 check: 26s (9s byte-compilation, 17s execution) vs 23s (7s 
> byte-compilation, 16s execution)

> In short, the compilation time in make check is slower (which is 
> expected), but the execution time in make check is also consistently ~7% 
> slower.

Yes.  But bug #22288 and friends are fixed.

I did some comparisons using elisp-benchmark earlier on today.  With the
bug fix, the timings were just 2½% slower.

Anything doing compilation (whether byte- or native-), or doing lots of
tight loops will be slower than that -2½%.

Other programs (such as CC Mode) which spend a lot of time in the regexp
engine, or garbage collection, or I/O, will have lost less than that

But the main thing is that longstanding bugs have been fixed.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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