git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Drastic jump in the time required for the test suite

From
Jeff King <peff@peff.net>
Date
Oct 19, 2016, 20:56 UTC
Message-ID
<20161019205638.m3ytxozzmeh47ml2@sigill.intra.peff.net>
In-Reply-To
<xmqqbmygmehv.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 19, 2016 at 10:32:12AM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> > 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.

Of course YMMV; the long tests on Windows may be different, or proportionally much longer (I note the worst cases almost all involve rebase, which as a shell script is presumably worse on Windows than elsewhere). And of course any reasoning about slow-to-fast order does not apply if you are not using a tool to do that for you. :)

-Peff
[1] After running "make prove" (time are in seconds):
    $ perl -MYAML -e '
        $_ = do { local $/; <> };
        # prove puts this non-YAML cruft at the end
        s/\.\.\.$//s;
        my $t = YAML::Load($_)->{tests};
        print "$_->[1] $_->[0]\n" for
          sort { $b->[1] <=> $a->[1] }
          map { [$_, $t->{$_}->{elapsed}] }
          keys(%$t);
      ' .prove | head
    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
Previous: Junio C HamanoNext: Johannes Schindelin
Message 3 of 31 in “Drastic jump in the time required for the test suite”
  1. Johannes SchindelinOct 19, 2016
  2. Junio C HamanoOct 19, 2016
  3. Jeff KingOct 19, 2016
  4. Johannes SchindelinOct 20, 2016
  5. Jeff KingOct 20, 2016
  6. Stefan BellerOct 20, 2016
  7. Jeff KingOct 20, 2016
  8. Stefan BellerOct 20, 2016
  9. Jeff KingOct 20, 2016
  10. Jeff KingOct 20, 2016
  11. Johannes SixtOct 21, 2016
  12. Jeff KingOct 21, 2016
  13. Johannes SchindelinOct 20, 2016
  14. Jeff KingOct 20, 2016
  15. Stefan BellerOct 20, 2016
  16. Jeff KingOct 20, 2016
  17. Jeff KingOct 20, 2016
  18. Johannes SixtOct 20, 2016
  19. Jeff KingOct 20, 2016
  20. Dennis KaarsemakerOct 20, 2016
  21. Duy NguyenOct 21, 2016
  22. Junio C HamanoOct 20, 2016
  23. Matthieu MoyOct 20, 2016
  24. Duy NguyenOct 20, 2016
  25. René ScharfeOct 20, 2016
  26. Duy NguyenOct 21, 2016
  27. René ScharfeOct 21, 2016
  28. Matthieu MoyOct 21, 2016
  29. René ScharfeOct 21, 2016
  30. Eric WongOct 27, 2016
  31. Duy NguyenOct 28, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.