Re: [PATCH] parse_object: try internal cache before reading object db

Jeff King [off-list ref] writes:

Actually, we can do much better than that. Here are a few patches that
avoid parsing objects when possible. They drop the 3.4s to 2.0s. If you
combine them with the parse_object optimization, my 120K case drops to
around 0.68s.

I don't know if it is really that worth it on top of the parse_object
optimization. It's almost negligible for the normal case...
... OTOH, if you had some totally insane ref
structure, like 120K _unique_ refs (which would probably imply that
you're making one ref per commit or something silly like that. But hey,
people have suggested it in the past), then it could be a big
improvement.

Even though it is a bit scary kind of loosening of sanity checks that I
hesitate to take at this late in the cycle, I think it makes sense. Let's
queue them on 'pu' and aim for the next cycle.

On Fri, Jan 06, 2012 at 01:27:40PM -0800, Junio C Hamano wrote:

quoted

I don't know if it is really that worth it on top of the parse_object
optimization. It's almost negligible for the normal case...
... OTOH, if you had some totally insane ref
structure, like 120K _unique_ refs (which would probably imply that
you're making one ref per commit or something silly like that. But hey,
people have suggested it in the past), then it could be a big
improvement.

Even though it is a bit scary kind of loosening of sanity checks that I
hesitate to take at this late in the cycle, I think it makes sense. Let's
queue them on 'pu' and aim for the next cycle.

Did you want to leave the parse_object optimization until next cycle,
too? It's not loosening checks, but it's such a core piece of code that
it makes me nervous somebody somewhere is abusing "struct object" in a
way that will break it.

-Peff