Re: [PATCH 5/5] reset: update cache-tree data when appropriate

From: Thomas Rast <trast@student.ethz.ch>
Date: Dec 7, 2011, 07:53 UTC
Message-ID: <201112070853.15364.trast@student.ethz.ch>
In-Reply-To: <7v62hte1k7.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 16 quoted lines

> Thomas Rast <trast@student.ethz.ch> writes:
> > @@ -84,6 +85,12 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
> >  		return error(_("Failed to find tree of %s."), sha1_to_hex(sha1));
> >  	if (unpack_trees(nr, desc, &opts))
> >  		return -1;
> > +
> > +	if (reset_type == MIXED || reset_type == HARD) {
> > +		tree = parse_tree_indirect(sha1);
> > +		prime_cache_tree(&active_cache_tree, tree);
> > +	}
> 
> The basic idea that MIXED or HARD should result in a cache-tree that match
> the tree we just read is sound, but how expensive is prime_cache_tree()? I
> think it reads the same tree once again. Admittedly, the data needed to
> reconstruct the tree is likely to be hot in core, but it may be necessary
> to measure before deciding if this is a good change.

Oh, I just didn't bother with timings because it's the same strategy that read-tree follows, so I assumed if it was worth it back then, it should again be a win.

For linux-2.6 as usual and best-of-10:

  git reset            before: 0:00.25real 0.12user 0.11system
	               after:  0:00.28real 0.14user 0.12system

  git reset --hard     before: 0:00.21real 0.13user 0.06system
                       after:  0:00.18real 0.10user 0.07system

So we spend ~30ms of extra user time, at a possible gain of 30% in future git-commit invocations, as mentioned in the cover letter. I think that's worth it :-)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch