From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Drastic jump in the time required for the test suite
Date: Thu, 20 Oct 2016 12:50:32 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1610201218060.3264@virtualbox> (raw)
In-Reply-To: <20161019205638.m3ytxozzmeh47ml2@sigill.intra.peff.net>
Hi peff,
On Wed, 19 Oct 2016, Jeff King wrote:
> On Wed, Oct 19, 2016 at 10:32:12AM -0700, Junio C Hamano wrote:
>
> > > Maybe we should start optimizing the tests...
> >
> > Yup, two things that come to mind are to identify long ones and see if
> > each of them can be split into two halves that can be run in parallel,
> > and to go through the tests with fine toothed comb and remove the ones
> > that test exactly the same thing as another test. The latter would be
> > very time consuming, though.
>
> FWIW, I have made attempts at "split long ones into two" before, and
> didn't come up with much. There _are_ some tests that are much longer
> than others[1], but they are not longer than the whole suite takes to
> run. So running in slow-to-fast order means they start first, are run in
> parallel with the other tests, and the CPUs stay relatively full through
> the whole run.
That reflects my findings, too. I want to add that I found preciously
little difference between running slow-to-fast and running in numeric
order, so I gave up on optimizing on that front.
> 43.216765165329 t3404-rebase-interactive.sh
> 30.6568658351898 t3421-rebase-topology-linear.sh
> 27.92564702034 t9001-send-email.sh
> 15.5906939506531 t9500-gitweb-standalone-no-errors.sh
> 15.4882569313049 t6030-bisect-porcelain.sh
> 14.487174987793 t7610-mergetool.sh
> 13.8276169300079 t3425-rebase-topology-merges.sh
> 12.7450480461121 t3426-rebase-submodule.sh
> 12.4915001392365 t3415-rebase-autosquash.sh
> 11.8122401237488 t5572-pull-submodule.sh
That looks very similar to what I found: t3404 on top, followed by t3421.
Further, I found that the Subversion tests (which run at the end) are so
close in their running time that running the tests in parallel with -j5
does not result in any noticeable improvement when reordered.
I guess I will have to bite into the sour apple and try to profile, say,
t3404 somehow, including all the shell scripting stuff, to identify where
exactly all that time is lost. My guess is that it boils down to
gazillions of calls to programs like expr.exe or merely subshells.
Ciao,
Dscho
next prev parent reply other threads:[~2016-10-20 10:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 9:18 Drastic jump in the time required for the test suite Johannes Schindelin
2016-10-19 17:32 ` Junio C Hamano
2016-10-19 20:56 ` Jeff King
2016-10-20 10:50 ` Johannes Schindelin [this message]
2016-10-20 11:39 ` Jeff King
2016-10-20 19:54 ` Stefan Beller
2016-10-20 21:38 ` Jeff King
2016-10-20 21:53 ` Stefan Beller
2016-10-20 21:57 ` Jeff King
2016-10-20 21:56 ` Jeff King
2016-10-21 5:27 ` Johannes Sixt
2016-10-21 8:24 ` Jeff King
2016-10-20 10:17 ` Johannes Schindelin
2016-10-20 12:31 ` Jeff King
2016-10-20 16:30 ` Stefan Beller
2016-10-20 21:00 ` Jeff King
2016-10-20 23:20 ` Jeff King
2016-10-20 20:38 ` Johannes Sixt
2016-10-20 21:03 ` Jeff King
2016-10-20 20:40 ` Dennis Kaarsemaker
2016-10-21 11:03 ` Duy Nguyen
2016-10-20 16:16 ` Junio C Hamano
2016-10-20 17:13 ` Matthieu Moy
2016-10-20 11:02 ` Duy Nguyen
2016-10-20 16:40 ` René Scharfe
2016-10-21 10:59 ` Duy Nguyen
2016-10-21 20:28 ` René Scharfe
2016-10-21 13:10 ` Matthieu Moy
2016-10-21 19:57 ` René Scharfe
2016-10-27 20:41 ` Eric Wong
2016-10-28 6:38 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1610201218060.3264@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).