Re: [PATCH v3 0/2] read-cache: call verify_hdr() in a background thread
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Mar 28, 2017, 19:50 UTC
- Message-ID
- <35f220df-aa63-b80f-8970-429850202cdd@jeffhostetler.com>
- In-Reply-To
- <20170328191628.dprziuhpv7khvocu@sigill.intra.peff.net>
On 3/28/2017 3:16 PM, Jeff King wrote:
Show 23 quoted lines
> On Tue, Mar 28, 2017 at 07:07:30PM +0000, git@jeffhostetler.com wrote: > >> From: Jeff Hostetler <jeffhost@microsoft.com> >> >> Version 3 of this patch series simplifies this effort to just turn >> on/off the hash verification using a "core.checksumindex" config variable. >> >> I've preserved the original checksum validation code so that we can >> force it on in fsck if desired. >> >> It eliminates the original threading model completely. >> >> Jeff Hostetler (2): >> read-cache: core.checksumindex >> test-core-checksum-index: core.checksumindex test helper >> >> Makefile | 1 + >> read-cache.c | 12 ++++++ >> t/helper/.gitignore | 1 + >> t/helper/test-core-checksum-index.c | 77 +++++++++++++++++++++++++++++++++++++ > > Do we still need test-core-checksum-index? Can we just time ls-files or > something in t/perf?
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.
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.
Jeff