Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

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