Re: Performance issue of 'git branch'
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Jul 25, 2009, 02:53 UTC
- Message-ID
- <alpine.LNX.2.00.0907242242310.2147@iabervon.org>
- In-Reply-To
- <alpine.LFD.2.01.0907241934260.3960@localhost.localdomain>
On Fri, 24 Jul 2009, Linus Torvalds wrote:
Show 33 quoted lines
> On Fri, 24 Jul 2009, david@lang.hm wrote: > > > On Fri, 24 Jul 2009, Linus Torvalds wrote: > > > > > On Fri, 24 Jul 2009, david@lang.hm wrote: > > > > > > > > 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.
I think it's actually easy enough to have a separate binary to handle the http walking, particularly since I've got code lying around to handle importing from a foreign VCS with a separate binary that I can just remove some of the features from.
-Daniel *This .sig left intentionally blank*