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

Re: Performance issue of 'git branch'

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:47:06

Possibly related (same subject, not in this thread)


On Fri, 24 Jul 2009, david@lang.hm wrote:
On Fri, 24 Jul 2009, Linus Torvalds wrote:
quoted
On Fri, 24 Jul 2009, david@lang.hm wrote:
quoted
what does the performance look like if you just do a static compile
instead?
I don't even know - I don't have a static version of curl. I could install
one, of course, but since I don't think that's the solution anyway, I'm
not going to bother.
I wasn't thinking a static version of curl, I was thinking a static version of
the git binaries. see how fast things could be if no startup linking was
nessasary.
Well, that's what I meant. If I add '-static' to the link flags, I get

	/usr/bin/ld: cannot find -lcurl
	collect2: ld returned 1 exit status

because I simply don't have a static library version of curl (and if I do 
NO_CURL, I fail the link due to not having a static version of zlib).

That's what I meant by "I could install a static version of curl" - I 
could install the debug libraries, but it just isn't a normal thing to do 
on any modern distribution. The right thing to do really would be to not 
have -lcurl for the main git binary at all.

Preferably done by having http walking handled by an external process (the 
way we already do rsync), but it's probably easier to just make all the 
clone/fetch/ls-remote things be a separate binary.

Of course, I'd personally solve the problem with NO_CURL=1, but that's 
probably not acceptable in general.

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