git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: david@lang.hm
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	"Carlos R. Mafra" <crmafra2@gmail.com>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Performance issue of 'git branch'
Date: Fri, 24 Jul 2009 15:18:44 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.1.10.0907241518120.28013@asgard.lang.hm> (raw)
In-Reply-To: <alpine.LFD.2.01.0907241505400.3960@localhost.localdomain>

On Fri, 24 Jul 2009, Linus Torvalds wrote:

> On Fri, 24 Jul 2009, Linus Torvalds wrote:
>>
>> 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.
>
> Here's the simple step#1: make 'git-http-fetch' be an external program
> rather than a built-in.
>
> Sadly, I have no idea hot to turn the transport.c code into an external
> walker sanely (turn the ref/object walkers into an exec of an external
> program). So we still end up linking with curl. But maybe somebody
> (Daniel? Dscho?) who knows the transport code could try to make it an
> external process?
>
> The performance angle of http fetching is non-existent, we really should
> try very hard to make the curl-dependent parts be in a binary of their
> own.

what does the performance look like if you just do a static compile 
instead?

David Lang

> 		Linus
>
> ---
>> From 3cfc50d497266dc73a414ed1460b36b712ad10de Mon Sep 17 00:00:00 2001
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Fri, 24 Jul 2009 14:54:55 -0700
> Subject: [PATCH] git-http-fetch: not a builtin
>
> We should really try to avoid having a dependency on the curl libraries
> for the core 'git' executable. It adds huge overheads, for no advantage.
>
> This splits up git-http-fetch so that it isn't built-in.  We still do
> end up linking with curl for the git binary due to the transport.c http
> walker, but that's at least partially an independent issue.
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> Makefile                             |    8 +++++++-
> git.c                                |    3 ---
> builtin-http-fetch.c => http-fetch.c |    5 ++++-
> 3 files changed, 11 insertions(+), 5 deletions(-)
> rename builtin-http-fetch.c => http-fetch.c (95%)
>
> diff --git a/Makefile b/Makefile
> index bde27ed..8cbd863 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -978,9 +978,12 @@ else
> 	else
> 		CURL_LIBCURL = -lcurl
> 	endif
> -	BUILTIN_OBJS += builtin-http-fetch.o
> +	PROGRAMS += git-http-fetch$X
> +
> +	# FIXME! Sadly 'transport.c' still needs these for the builtin case
> 	EXTLIBS += $(CURL_LIBCURL)
> 	LIB_OBJS += http.o http-walker.o
> +
> 	curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
> 	ifeq "$(curl_check)" "070908"
> 		ifndef NO_EXPAT
> @@ -1485,6 +1488,9 @@ git-imap-send$X: imap-send.o $(GITLIBS)
>
> http.o http-walker.o http-push.o transport.o: http.h
>
> +git-http-fetch$X: revision.o http.o http-push.o $(GITLIBS)
> +	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> +		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
> git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
> 	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> 		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
> diff --git a/git.c b/git.c
> index 807d875..c1e8f05 100644
> --- a/git.c
> +++ b/git.c
> @@ -309,9 +309,6 @@ static void handle_internal_command(int argc, const char **argv)
> 		{ "get-tar-commit-id", cmd_get_tar_commit_id },
> 		{ "grep", cmd_grep, RUN_SETUP | USE_PAGER },
> 		{ "help", cmd_help },
> -#ifndef NO_CURL
> -		{ "http-fetch", cmd_http_fetch, RUN_SETUP },
> -#endif
> 		{ "init", cmd_init_db },
> 		{ "init-db", cmd_init_db },
> 		{ "log", cmd_log, RUN_SETUP | USE_PAGER },
> diff --git a/builtin-http-fetch.c b/http-fetch.c
> similarity index 95%
> rename from builtin-http-fetch.c
> rename to http-fetch.c
> index f3e63d7..e8f44ba 100644
> --- a/builtin-http-fetch.c
> +++ b/http-fetch.c
> @@ -1,8 +1,9 @@
> #include "cache.h"
> #include "walker.h"
>
> -int cmd_http_fetch(int argc, const char **argv, const char *prefix)
> +int main(int argc, const char **argv)
> {
> +	const char *prefix;
> 	struct walker *walker;
> 	int commits_on_stdin = 0;
> 	int commits;
> @@ -18,6 +19,8 @@ int cmd_http_fetch(int argc, const char **argv, const char *prefix)
> 	int get_verbosely = 0;
> 	int get_recover = 0;
>
> +	prefix = setup_git_directory();
> +
> 	git_config(git_default_config, NULL);
>
> 	while (arg < argc && argv[arg][0] == '-') {
>

  reply	other threads:[~2009-07-24 22:19 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
2009-07-24 22:13                             ` Linus Torvalds
2009-07-24 22:18                               ` david [this message]
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.DEB.1.10.0907241518120.28013@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=crmafra2@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=torvalds@linux-foundation.org \
    /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).