[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: Gregory Heytings
Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps?
Date: Mon, 24 Jan 2022 15:20:26 +0000

and what does "execution time" stand for -- is that elapsed time, CPU time, something else?

The first time printed by "time", that is, the wall clock time.

If you are measuring wallclock time, I don't see how the overall slowdown is a reliable measure of any code performance. The test suite includes quite a few tests that deliberately wait for some seconds for various reasons, and those times aren't affected by the byte code or the interpreter.

It is reliable, because the slowdown ratio doesn't change between -j1, -j4 and -j8.

We need to measure CPU time.

The results are even worse (again 7922131bb2 vs 3b33a14380):

make -j1 check: 153.7s (68.1s byte-compilation, 85.6s execution) vs 135.8s 
(58.1s byte-compilation, 77.7s execution)
make -j4 check: 151.0s (67.5s byte-compilation, 83.5s execution) vs 132.3s 
(57.3s byte-compilation, 75.0s execution)
make -j8 check: 149.2s (65.5s byte-compilation, 83.7s execution) vs 130.3s 
(55.8s byte-compilation, 74.5s execution)

These numbers are the average of 20 runs in sequence, on an unloaded up-to-date Debian bookworm machine.

In short: byte-compilation is ~17.5% slower, execution is ~11% slower. Nowhere near the "in the region of 1%" that was announced.

reply via email to

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