Re: Significant performance waste in git-svn and friends

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: Significant performance waste in git-svn and friends

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:33

Junio C Hamano [off-list ref] writes:
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.

I wonder if letting fast-import handle the object creation is an
option, though.
I think it would be saner to give git-hash-object an operation mode
that makes it usable as a pipe-controlled daemon, so that one needs
not fork and exec for interning another object.  That way, porcelain
commands could keep one bidirectional pipe (feed object type and
source and whether to use -w into git-hash-project, receive object id)
to git-hash-object around until they finish.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Significant performance waste in git-svn and friends

From: Patrick Doyle <hidden>
Date: 2016-06-15 22:43:33

I'll add my hearty vote of support, and perhaps even a patch or two,
to anything that would make git-svn faster.  Just last week, I gave up
waiting for it to complete the import of a (rather large) uClinux
distribution, falling back on SVN.  I'm looking forward to trying it
again with Mike's patch, or perhaps even implementing and trying out
David's idea.

Hmmm.... I'm supposed to be on a couple of planes for a rather longish
period of time next week.  Perhaps I'll give it a shot.  (But don't
count on much -- the laptop battery is pretty shot nowadays and, given
the nature of the rest of the participitants on this list, it'll
probably be implemented and tested by the time I pack up for the
trip.)

--wpd

Re: Significant performance waste in git-svn and friends

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:43:33

David Kastrup [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
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 wonder if letting fast-import handle the object creation is an
option, though.
I think it would be saner to give git-hash-object an operation mode
that makes it usable as a pipe-controlled daemon, so that one needs
not fork and exec for interning another object.  That way, porcelain
commands could keep one bidirectional pipe (feed object type and
source and whether to use -w into git-hash-project, receive object id)
to git-hash-object around until they finish.
Aside from getting the hashes back from fast-import, that's what
fast-import is for.  I could also make it disable writing.  Hmm.
Junio and I were just talking about making fast-import send the
marks table back out on stdout.  This would make it easier for a
frontend process to stream a whole bunch of objects into the process,
then get back all of their SHA-1s.  Less context switches and more
parallel operation.

-- 
Shawn.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help