Re: Why pack+unpack?

From: Jeff Garzik <jgarzik@pobox.com>
Date: Jul 26, 2005, 05:13 UTC
Message-ID: <42E5C677.2020403@pobox.com>
In-Reply-To: <Pine.LNX.4.58.0507252145470.6074@g5.osdl.org>

Linus Torvalds wrote:

> First, make sure you have a recent git, it does better at optimizing the

I was using vanilla git, as of 10 minutes before I sent the email. Top of tree is 154d3d2dd2656c23ea04e9d1c6dd4e576a7af6de.

Show 12 quoted lines

> Secondly, what's the problem? Sure, I could special-case the local case, 
> but do you really want to have two _totally_ different code-paths? In 
> other words, it's absolutely NOT a complete waste of time: it's very much 
> a case of trying to have a unified architecture, and the fact that it 
> spends a few seconds doing things in a way that is network-transparent is 
> time well spent.
> 
> Put another way: do you argue that X network transparency is a total waste
> of time? You could certainly optimize X if you always made it be
> local-machine only. Or you could make tons of special cases, and have X 
> have separate code-paths for local clients and for remote clients, rather 
> than just always opening a socket connection.

Poor example... sure it opens a socket, but X certainly does have a special case local path (mit shm), and they're adding more for 3D due the massive amount of data involved in 3D.

Show 5 quoted lines

> We do end up having a special code-path for "clone" (the "-l" flag), which
> does need it, but I seriously doubt you need it for a local pull. The most 
> expensive operation in a local pull tends to be (if the repositories are 
> unpacked and cold-cache) just figuring out the objects to pull, not the 
> packing/unpacking per se.

Well, I'm not overly concerned, mostly curious. The pack+unpack step (a) appears completely redundant and (b) is the step that takes the most time here, for local pulls, after the diffstat.

	Jeff