From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Carlos R. Mafra" <crmafra2@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Performance issue of 'git branch'
Date: Fri, 24 Jul 2009 14:21:20 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0907241349390.3960@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.01.0907241346450.3960@localhost.localdomain>
On Fri, 24 Jul 2009, Linus Torvalds wrote:
>
> Never mind. I'm seeing even worse behavior on a laptop I just dug up
> (another 4200 rpm harddisk).
>
> I'll dig some more.
Yeah, it seems to be the loading overhead. I'm seeing a 'time git branch'
take 1.2s in the cold-cache case, in a directory that isn't even a git
directory.
And 80% of it comes before we even get to 'main()'. Shared library
loading, SELinux crud etc. A lot of it seems to be 'libfreebl3' and
'libselinux', which is some crazy sh*t.
It seems to be all from 'curl' support.
That seems _really_ sad. Lookie here:
[torvalds@nehalem git]$ ldd git
linux-vdso.so.1 => (0x00007fff61da7000)
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f2f1a498000)
libz.so.1 => /lib64/libz.so.1 (0x0000003cdb800000)
libcrypto.so.8 => /usr/lib64/libcrypto.so.8 (0x0000003ba7a00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003cdb400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003cda800000)
libidn.so.11 => /lib64/libidn.so.11 (0x0000003ceaa00000)
libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x0000003ba8e00000)
libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f2f1a250000)
librt.so.1 => /lib64/librt.so.1 (0x0000003cdbc00000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003ce6e00000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003ce7e00000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003ce7200000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003ce6a00000)
libssl3.so => /lib64/libssl3.so (0x0000003490200000)
libsmime3.so => /lib64/libsmime3.so (0x000000348fe00000)
libnss3.so => /lib64/libnss3.so (0x000000348f600000)
libplds4.so => /lib64/libplds4.so (0x0000003cbc800000)
libplc4.so => /lib64/libplc4.so (0x0000003cbdc00000)
libnspr4.so => /lib64/libnspr4.so (0x0000003cbd800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003cdb000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003cda400000)
libssl.so.8 => /usr/lib64/libssl.so.8 (0x0000003ba7e00000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x0000003ceee00000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003ce5600000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f2f1a030000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003ce7a00000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003ce7600000)
libnssutil3.so => /lib64/libnssutil3.so (0x000000348fa00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2f19df8000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003cdc400000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f2f19b99000)
[torvalds@nehalem git]$ make -j16 NO_CURL=1
[torvalds@nehalem git]$ ldd git
linux-vdso.so.1 => (0x00007fff2f960000)
libz.so.1 => /lib64/libz.so.1 (0x0000003cdb800000)
libcrypto.so.8 => /usr/lib64/libcrypto.so.8 (0x0000003ba7a00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003cdb400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003cda800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003cdb000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003cda400000)
What a huge difference!
And the NO_CURL version really does load a lot faster in cold-cache. We're
not talking small differences:
- compiled with NO_CURL, five runs of "echo 3 > /proc/sys/vm/drop_caches"
followed by "time git branch":
real 0m0.654s
real 0m0.562s
real 0m0.519s
real 0m0.534s
real 0m0.734s
Total number of system calls: 194
- compiled with curl, same thing:
real 0m1.503s
real 0m1.455s
real 0m1.267s
real 0m1.819s
real 0m0.985s
Total number of system calls: 407!
ie we're talking a _huge_ hit in startup times for that curl support.
That's really really sad - especially considering how all the curl support
is for very random occasional stuff. I never use it myself, for example,
since I don't use http at all. And even for people who do, they only need
it for non-local operations.
I wonder if there is some way to only load the crazy curl stuff when we
actually want open a http: connection.
Linus
next prev parent reply other threads:[~2009-07-24 21:22 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-22 23:59 Performance issue of 'git branch' Carlos R. Mafra
2009-07-23 0:21 ` Linus Torvalds
2009-07-23 0:51 ` Linus Torvalds
2009-07-23 0:55 ` Linus Torvalds
2009-07-23 2:02 ` Carlos R. Mafra
2009-07-23 2:28 ` Linus Torvalds
2009-07-23 12:42 ` Jakub Narebski
2009-07-23 14:45 ` Carlos R. Mafra
2009-07-23 16:25 ` Linus Torvalds
2009-07-23 1:22 ` Carlos R. Mafra
2009-07-23 2:20 ` Linus Torvalds
2009-07-23 2:23 ` Linus Torvalds
2009-07-23 3:08 ` Linus Torvalds
2009-07-23 3:21 ` Linus Torvalds
2009-07-23 17:47 ` Tony Finch
2009-07-23 18:57 ` Linus Torvalds
2009-07-23 22:48 ` Newton-Raphson, was " Tony Finch
2009-07-23 23:24 ` Johannes Schindelin
2009-07-23 23:50 ` Tony Finch
2009-07-24 0:43 ` Johannes Schindelin
2009-07-23 3:18 ` Carlos R. Mafra
2009-07-23 3:27 ` Carlos R. Mafra
2009-07-23 3:40 ` Carlos R. Mafra
2009-07-23 3:47 ` Linus Torvalds
2009-07-23 4:10 ` Linus Torvalds
2009-07-23 5:13 ` Junio C Hamano
2009-07-23 5:17 ` Carlos R. Mafra
2009-07-23 4:40 ` Junio C Hamano
2009-07-23 5:36 ` Linus Torvalds
2009-07-23 5:52 ` Junio C Hamano
2009-07-23 6:04 ` Junio C Hamano
2009-07-23 17:19 ` Linus Torvalds
2009-07-23 16:07 ` Carlos R. Mafra
2009-07-23 16:19 ` Linus Torvalds
2009-07-23 16:53 ` Carlos R. Mafra
2009-07-23 19:05 ` Linus Torvalds
2009-07-23 19:13 ` Linus Torvalds
2009-07-23 19:55 ` Carlos R. Mafra
2009-07-24 20:36 ` Linus Torvalds
2009-07-24 20:47 ` Linus Torvalds
2009-07-24 21:21 ` Linus Torvalds [this message]
2009-07-24 22:13 ` Linus Torvalds
2009-07-24 22:18 ` david
2009-07-24 22:42 ` Linus Torvalds
2009-07-24 22:46 ` david
2009-07-25 2:39 ` Linus Torvalds
2009-07-25 2:53 ` Daniel Barkalow
2009-08-07 4:21 ` Jeff King
2009-07-24 22:54 ` Theodore Tso
2009-07-24 22:59 ` Shawn O. Pearce
2009-07-24 23:28 ` Junio C Hamano
2009-07-26 17:07 ` Avi Kivity
2009-07-26 17:16 ` Johannes Schindelin
2009-07-24 23:46 ` Carlos R. Mafra
2009-07-25 0:41 ` Carlos R. Mafra
2009-07-25 18:04 ` Linus Torvalds
2009-07-25 18:57 ` Timo Hirvonen
2009-07-25 19:06 ` Reece Dunn
2009-07-25 20:31 ` Mike Hommey
2009-07-25 21:02 ` Linus Torvalds
2009-07-25 21:13 ` Linus Torvalds
2009-07-25 23:23 ` Johannes Schindelin
2009-07-26 4:49 ` Linus Torvalds
2009-07-26 16:29 ` Theodore Tso
2009-07-26 7:54 ` Mike Hommey
2009-07-26 10:16 ` Johannes Schindelin
2009-07-26 10:23 ` demerphq
2009-07-26 10:27 ` demerphq
2009-07-25 21:04 ` Carlos R. Mafra
2009-07-23 16:48 ` Anders Kaseorg
2009-07-23 19:03 ` Carlos R. Mafra
2009-07-23 0:23 ` SZEDER Gábor
2009-07-23 2:25 ` Carlos R. Mafra
-- strict thread matches above, loose matches on Subject: below --
2009-07-26 23:21 George Spelvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.01.0907241349390.3960@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=crmafra2@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).