On Fri, 2017-11-03 at 12:11 -0700, Stefan Beller wrote:
> On Fri, Nov 3, 2017 at 2:32 AM, Kaartic Sivaraam
> <kaartic.sivar...@gmail.com> wrote:
> > BTW, this is what I call _way way_ faster. Unfortunately due to the limited
> > configuration of my system, the test suite has following timing
> >
> > real 3m14.482s
> > user 2m10.556s
> > sys 1m12.328s
>
> This sounds to me as if it is running with just one thread
> (because sys+user = real); I usually run with
>
> cd t
> prove --jobs 25 t[0-8][0-9]*.sh
>
> The multithreading can be seen in the timing as well
> real 1m9.913s
> user 1m50.796s
> sys 0m54.092s
> as user > real already.
>
> If you run tests via 'make test' or 'cd t && make', you can also give
> a --jobs <n>
> to make it faster. I have no good answer for how many, but I have the
> impression
> overloading the system is no big deal. (I only have a few cores in this
> machine,
> 4 or 6, but still run with --jobs 25; 'git grep sleep' returns a
> couple of lines,
> and such threads sleeping definitely don't need a CPU)
>
I usually use the following command to build and run the test suite
from the root of the working directory,
make NO_GETTEXT=1 DEVELOPER=1 DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS="--timer --jobs 16" test
I beleived that the DEFAULT_TST_TARGE and GIT_PROVE_OPTS options would
be seen by the Makefile in t/ but didn't verify it. Your statement made
me suspicious and I wanted to know whether my assumption was correct or
not. So, I did this,
1. I first tried running the above command while seeing how much time
on the 'next' branch when it was pointing at,
9a519c715 (Merge branch 'jk/rebase-i-exec-gitdir-fix' into next, 2017-11-02)
First, I observed that at least part of my assumption held on observing
that the output was similar to that of 'prove'. This shows that
t/Makefile recognizes DEFAULT_TEST_TARGET.
Next, to verify if it recognizes GIT_PROVE_OPTS I ran the above command
with 'time' and it gave back the following statistics,
real 4m55.707s
user 2m29.924s
sys 1m48.072s
which is in line with the statistics for the spinning disk in the
previous mail. (The time doesn't include the build time).
(real)-(user+sys) = 38s (approx.)
2. Now I switched to the t/ directory, I tried running the following,
make DEFAULT_TEST_TARGET=prove GIT_PROVE_OPTS="--timer --jobs 16"
'time' gave the statistics for the above command as follows,
real 5m19.523s
user 2m26.764s
sys 1m45.240s
(real)-(user+sys) = 68s (approx.)
Not a big improvement from the previous case to assure that
GIT_PROVE_OPTS wasn't recognized there.
3. Staying in the t/ directory, I tried running the following just to
be pretty sure that the "--jobs" was indeed sent to 'prove',
prove --jobs 16 t[0-9][0-9]*.sh
'time' gave the statistics for the above command as follows,
real 4m49.241s
user 2m29.220s
sys 1m47.828s
(real)-(user+sys) = 34s (approx.)
This seems to be identical with the first case.
So, it does seem to be a limitation of my system (Intel i3 with 2
cores, FWIW).
4. To see if things improve with a higher number of jobs I tried,
prove --jobs 25 t[0-9][0-9]*.sh
'time' gave the statistics for the above command as follows,
real 5m21.229s
user 2m25.704s
sys 1m46.744s
(real)-(user+sys) = 70s (approx.)
This ensured the limitation once more!
Anyways, thanks for the explanation and information which was
enlightening. :-)
--
Kaartic
