Re: Significant performance waste in git-svn and friends

Mike Hommey [off-list ref] writes:

The same things obviously apply to git-cvsimport and other scripts
calling git-hash-object a lot.

I *obviously* hate this patch, as it makes this Porcelain
command to be aware of the internal representation too much.

I wonder if letting fast-import handle the object creation is an
option, though.

Junio C Hamano [off-list ref] wrote:

Mike Hommey [off-list ref] writes:

quoted

The same things obviously apply to git-cvsimport and other scripts
calling git-hash-object a lot.

I *obviously* hate this patch, as it makes this Porcelain
command to be aware of the internal representation too much.

Me too.  I think its bad enough that fast-import knows the
internal representation of a packfile.  And its plumbing!
 

I wonder if letting fast-import handle the object creation is an
option, though.

I agree.  This is *exactly* what fast-import was built for.  It
really would be the better tool to use here.  Much better than
reinventing the wheel.  Its already been invented twice for you
in Git (normal object creation path and fast-import path).  No
need to do it a third time.

-- 
Shawn.

On Wed, Sep 05, 2007 at 01:40:42PM -0700, Junio C Hamano [off-list ref] wrote:

Mike Hommey [off-list ref] writes:

quoted

The same things obviously apply to git-cvsimport and other scripts
calling git-hash-object a lot.

I *obviously* hate this patch, as it makes this Porcelain
command to be aware of the internal representation too much.

The patch was not supposed to be applied. I said it was lame ;)
It was more of a proof of concept.

Anyways, thinking a bit more about it, I was wondering if it wouldn't be
a good idea to have Git.pm have a "native" implementation (by native I
mean a .so module) for low-level plumbing tools such as hash-object,
cat-file and such.

Obviously, reinventing the wheel is not good, so this native
implementation would be using a "git library" API, such as what has
been done under SoC (though I don't know if this API exposes low-level
plumbing functions)

I wonder if letting fast-import handle the object creation is an
option, though.

It could, probably. The reason I didn't use it is that it was way
quicker to hack a 10 lines patch to create the blobs by hand than it
would have been to fork a fast-import object at the correct place during
git-svn initialization and piping to it at the appropriate times.

My goal was only to check how faster this would make it not to fork a
git-hash-object per blob.

Mike