Re: [PATCH] C implementation of the 'git' program.

From: Petr Baudis <pasky@suse.cz>
Date: Nov 10, 2005, 23:37 UTC
Message-ID: <20051110233751.GD30496@pasky.or.cz>
In-Reply-To: <4373CEA8.1020900@op5.se>

Dear diary, on Thu, Nov 10, 2005 at 11:50:16PM CET, I got a letter where Andreas Ericsson <ae@op5.se> said that...

Show 7 quoted lines

> Linus Torvalds wrote:
> >
> >And the performance difference does seem to be quite noticeable too..
> >
> 
> Yes. I was quite astonished when I noticed first, thinking the shell 
> kept the parsed script in cache or some such. Apparently it doesn't.

The bulk of the time is likely not spent parsing, but executing subprocesses, that's hideously expensive. Just for fun, you can try to measure the improvement when you remove the $(dirname "$0"). Here, for 1000 tries it's roughly 9s normal, 7s without dirname and 3s direct invocation, which seems to give you _very roughly_ 2s per subprocess, and 2s other shell overhead, which is unusually right.

Actually, I can bring the git.sh runtime from 7s to 4.7s:

-       case "$cmd" in
-       -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+       if [[ "$cmd" = "-v" ||
+             "$cmd" = "--v" ||
+             "$cmd" = "--ve" ||
+             "$cmd" = "--ver" ||
+             "$cmd" = "--vers" ||
+             "$cmd" = "--versi" ||
+             "$cmd" = "--versio" ||
+             "$cmd" = "--version" ]]; then
                echo "git version @@GIT_VERSION@@"
                exit 0 ;;
-       esac
+       fi
				(whitespace-mangled)

Well, subconsciously I never really trusted this case thing. ;-)

This leaves ~ 1.7s to other shell overhead and execve() (the main command call is without the fork(), while $(dirname) fork()s).

Show 15 quoted lines

> >>The location of the GIT_LIB can be obtained by running
> >>
> >>	git --lib
> >
> >
> >I think this might be a bit ambiguous. When I see "GIT_LIB", to me it 
> >implies traditional libraries (ie a "libgit.a" kind of thing), not the 
> >kind of "git executable plugin" directory.
> >
> >So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a "--libexec" 
> >kind of flavor, if only to avoid that confusion.
> 
> 
> Someone said libexec was moving out (of Linux, at least), so I thought 
> I'd better avoid that. Perhaps GIT_LIBDIR?

This may not necessarily have anything in common with the actual directory name. I prefer libexec too (but personally don't care too much).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.