Re: "Cannot fetch git.git" ( iworktrees at fault? or origin/HEAD) ?

[Kaartic Sivaraam <kaartic.sivaraam@gmail.com>]

On Fri, 2017-11-03 at 12:11 -0700, Stefan Beller wrote:
> On Fri, Nov 3, 2017 at 2:32 AM, Kaartic Sivaraam
> <kaartic.sivaraam@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