Jeff King <p...@peff.net> writes: > Of course any cache raises questions of cache invalidation, but I think > we've already dealt with that for this case. When we use > OBJECT_INFO_QUICK, that is a sign that we want to make this kind of > accuracy/speed tradeoff (which does a similar caching thing with > packfiles). > > So putting that all together, could we have something like:
I think this conceptually is a vast improvement relative to ".cloning" optimization. Obviously this does not have the huge downside of the other approach that turns the collision detection completely off. A real question is how much performance gain, relative to ".cloning" thing, this approach gives us. If it gives us 80% or more of the gain compared to doing no checking, I'd say we have a clear winner. > That's mostly untested, but it might be enough to run some timing tests > with. I think if we want to pursue this, we'd want to address the bits I > mentioned in the comments, and look at unifying this with the loose > cache from cc817ca3ef (which if I had remembered we added, probably > would have saved some time writing the above ;) ). Yup.
