On 3/30/2017 4:44 PM, Junio C Hamano wrote:
Jeff King writes:
Still, I'm not sure the extra layer of cache is all that valuable. It
should be a single hash lookup in the config cache (in an operation that
otherwise reads the entire index).
OK, let's drop that part, then.
Yes, let's omit
On 3/30/2017 4:39 PM, Jeff King wrote:
On Thu, Mar 30, 2017 at 09:06:48PM +0100, Thomas Gummerer wrote:
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
Jeff King writes:
> Still, I'm not sure the extra layer of cache is all that valuable. It
> should be a single hash lookup in the config cache (in an operation that
> otherwise reads the entire index).
OK, let's drop that part, then.
On Thu, Mar 30, 2017 at 09:06:48PM +0100, Thomas Gummerer wrote:
> > 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 sh
On 03/28, Jeff King wrote:
> 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
> >
On Thu, Mar 30, 2017 at 12:49:15PM -0700, Junio C Hamano wrote:
> Notable suggested changes I have in this one are:
>
> * I stole the numbers from the cover letter of v2 and added them at
>the end of the log message.
Yeah, good.
> * As the checksum is not a useless relic, but is an integr
Jeff King writes:
> So just mentioning the test case and the improvement in the commit
> message is sufficient, IMHO.
So here is how I butchered [v3 1/2] to tentatively queue it on 'pu'.
Notable suggested changes I have in this one are:
* I stole the numbers from the cover letter of v2 and ad
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 tr
On 3/28/2017 3:16 PM, Jeff King wrote:
On Tue, Mar 28, 2017 at 07:07:30PM +, g...@jeffhostetler.com wrote:
From: Jeff Hostetler
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 t
On Tue, Mar 28, 2017 at 07:07:30PM +, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> 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
From: Jeff Hostetler
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 threa
11 matches
Mail list logo
