Re: pack-object's try_delta fast path for v2 trees?

From: Nicolas Pitre <nico@fluxnic.net>
Date: Oct 15, 2013, 02:13 UTC
Message-ID: <alpine.LFD.2.03.1310142200380.1873@syhkavp.arg>
In-Reply-To: <20131015015113.GA17486@sigill.intra.peff.net>

On Mon, 14 Oct 2013, Jeff King wrote:

> By the way, I'm sorry I haven't looked more carefully at the packv4
> patches yet. I am excited about it, but I've just got a long queue of
> other things (and because it's big and challenging, it's easy to put
> off).

;-)

While I consider the format pretty much established at this point, it still has some way to go on the algorithmic side of things. So there is certainly room for more people toying with the code.

Show 7 quoted lines

> One of the things that makes me most nervous about switching to it on
> the server side is that we'll have packv2-only clients for a while, and
> I worry that converting to v2 on the fly is going to end up costing a
> lot (even with clever tricks like this, you still have to pay the cost
> to zlib deflate each item). But even if it is slow, the sooner we have
> packv4 readers, the sooner the clocks start ticking for it being a
> reasonable decision for a big server provider to switch.

Well... of course this depends. What pack v4 brings is super fast tree walking and object enumeration. We're not there yet with the current code, but in theory this is conceptually cheaper with pack v4. Therefore operations such as partial clones or updates are meant to be much faster in the preparation phase which should compensate for the deflate cost.

Yet a big server could store both v2 and v4 in parallel if disk space is not an issue, and a modified git could lookup the alternate version of an object before transcoding it.

Nicolas