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

Re: [PATCH v3 0/2] read-cache: call verify_hdr() in a background thread

From
Jeff King <peff@peff.net>
Date
Mar 28, 2017, 19:56 UTC
Message-ID
<20170328195605.xy4pnhy74s6wgwps@sigill.intra.peff.net>
In-Reply-To
<35f220df-aa63-b80f-8970-429850202cdd@jeffhostetler.com>
On Tue, Mar 28, 2017 at 03:50:34PM -0400, Jeff Hostetler wrote:
Show 7 quoted lines
> It was a convenient way to isolate, average, and compare
> read_index() times, but I suppose we could do something
> like that.
> 
> I did confirm that a ls-files does show a slight 0.008
> second difference on the 58K file Linux tree when toggled
> on or off.

Yeah, I agree it helps isolate the change. I'm just not sure we want to carry a bunch of function-specific perf-testing code. And one of the nice things about testing a real command is that it's...a real command. So it's an actual improvement a user might see.

Show 5 quoted lines
> But I'm tempted to suggest that we just omit my helper exe
> and not worry about a test -- since we don't have any test
> repos large enough to really demonstrate the differences.
> My concern is that that 0.008 would be lost in the noise
> of the rest of the test and make for an unreliable result.

Yeah, I think that would be fine. You _could_ write a t/perf test and then use your 400MB monstrosity as GIT_PERF_LARGE_REPO. But given that most people don't have such a thing, there's not much value over you just showing off the perf improvement in the commit message.

We could also have a t/perf test that generates a monstrous index and shows that it's faster. But frankly, I don't think this is all that interesting as a performance regression test. It's not like there's something subtle about the performance improvement; we stopped computing the SHA-1, and (gasp!) it takes exactly one SHA-1 computation's less time.

So just mentioning the test case and the improvement in the commit message is sufficient, IMHO.

-Peff
Previous: Jeff HostetlerNext: Junio C Hamano
Message 6 of 13 in “read-cache: call verify_hdr() in a background thread”
  1. 0/2 read-cache: call verify_hdr() in a background threadgit@jeffhostetler.com, Mar 28, 2017
  2. 1/2 read-cache: core.checksumindexgit@jeffhostetler.com, Mar 28, 2017
  3. 2/2 test-core-checksum-index: core.checksumindex test helpergit@jeffhostetler.com, Mar 28, 2017
  4. Jeff KingMar 28, 2017
  5. Jeff HostetlerMar 28, 2017
  6. Jeff KingMar 28, 2017
  7. Junio C HamanoMar 30, 2017
  8. Jeff KingMar 30, 2017
  9. Junio C HamanoMar 30, 2017
  10. Jeff HostetlerMar 31, 2017
  11. Thomas GummererMar 30, 2017
  12. Jeff KingMar 30, 2017
  13. Jeff HostetlerMar 31, 2017

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.