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

Re: [PATCH 0/5] handling 4GB .idx files

From
Taylor Blau <me@ttaylorr.com>
Date
Dec 1, 2020, 18:27 UTC
Message-ID
<X8aLDlzcNCwP699c@nand.local>
In-Reply-To
<X8YnsGsUl53OKFno@coredump.intra.peff.net>
On Tue, Dec 01, 2020 at 06:23:28AM -0500, Jeff King wrote:
Show 12 quoted lines
> I'm not sure if EXPENSIVE is the right ballpark, or if we'd want a
> VERY_EXPENSIVE. On my machine, the whole test suite for v2.29.0 takes 64
> seconds to run, and setting GIT_TEST_LONG=1 bumps that to 103s. It got a
> bit worse since then, as t7900 adds an EXPENSIVE test that takes ~200s
> (it's not strictly additive, since we can work in parallel on other
> tests for the first bit, but still, yuck).
>
> So we're looking at 2-3x to run the expensive tests now. This new one
> would be 20x or more. I'm not sure if anybody would care or not (i.e.,
> whether anyone actually runs the whole suite with this flag). I thought
> we did for some CI job, but it looks like it's just the one-off in
> t5608.

I had written something similar yesterday before mutt crashed and I decided to stop work for the day.

I have a sense that probably very few people actually run GIT_TEST_LONG regularly, and that that group may vanish entirely if we added a test which increased the runtime of the suite by 20x in this mode.

I have mixed feelings about VERY_EXPENSIVE. On one hand, having this test checked in so that we can quickly refer back to it in the case of a regression is useful. On the other hand, what is it worth to have this in-tree if nobody ever runs it? I'm speculating about whether or not people would run this, of course.

My hunch is that anybody who is interested enough to fix regressions in this area would be able to refer back to the list archive to dig up this thread and recover the script.

I don't feel strongly, really, but just noting some light objections to checking this test into the suite.

Thanks, Taylor

Previous: Derrick StoleeNext: Jeff King
Message 18 of 19 in “handling 4GB .idx files”
  1. 0/5 handling 4GB .idx filesJeff King, Nov 13, 2020
  2. 1/5 compute pack .idx byte offsets using size_tJeff King, Nov 13, 2020
  3. 2/5 use size_t to store pack .idx byte offsetsJeff King, Nov 13, 2020
  4. 3/5 fsck: correctly compute checksums on idx files larger than 4GBJeff King, Nov 13, 2020
  5. 4/5 block-sha1: take a size_t length parameterJeff King, Nov 13, 2020
  6. 5/5 packfile: detect overflow in .idx file size checksJeff King, Nov 13, 2020
  7. Johannes SchindelinNov 13, 2020
  8. Thomas BraunNov 15, 2020
  9. Jeff KingNov 16, 2020
  10. Derrick StoleeNov 16, 2020
  11. Jeff KingNov 16, 2020
  12. Thomas BraunNov 30, 2020
  13. Jeff KingDec 1, 2020
  14. t7900's new expensive testJeff King, Dec 1, 2020
  15. Derrick StoleeDec 1, 2020
  16. t7900: speed up expensive testJeff King, Dec 2, 2020
  17. Derrick StoleeDec 3, 2020
  18. Taylor BlauDec 1, 2020
  19. Jeff KingDec 2, 2020

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.