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
Thomas Gummerer <t.gummerer@gmail.com>
Date
Mar 30, 2017, 20:06 UTC
Message-ID
<20170330200648.GH27158@hank>
In-Reply-To
<20170328195605.xy4pnhy74s6wgwps@sigill.intra.peff.net>
On 03/28, Jeff King wrote:
Show 25 quoted lines
> On Tue, Mar 28, 2017 at 03:50:34PM -0400, Jeff Hostetler wrote:
> 
> > 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.
> 
> > 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.

Sorry if this was already discussed, but we already do have a perf test for the index (p0002), and a corresponding helper program which just does read_cache() and discard_cache(). Maybe we could re-use that and add a second test running the same using the new config?

Show 11 quoted lines
> 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: Jeff King
Message 11 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.