On Sun, 10 Sep 2006, linux@xxxxxxxxxxx wrote: > > A direct fork() (or even faster, vfork) and exec() is going to have a > lot less overhead, although it's more work to code. See Stevens for > excellent examples. Well, that said, the Linux fork/exec/exit is certainly fairly efficient, but nothing can hide the fact that it _is_ a very expensive operation. So we may do a fork/exit in a millisecond, but on the other hand, we can generally open a file in a microsecond. So we're definitely talking about several orders of magnitude difference.. And a lot of the trivial git helpers are literally not doing a lot more than opening a file, reading it, and parsing it. That's for things like looking up the SHA1 of a branch head, for example. Doing it in-line might be a microsecond or two, while spawning a shell to execute git-rev-parse will take you several microseconds. Do it a million times, and the difference is now a second vs an hour. Or a few minutes vs a week. So in that sense, it is absolutely undeniable that fork/exit is slow. Everything is relative. The Linux fork/exit is fast when compared to most other systems fork/exit, but it's slow as hell when compared to just doing some small op directly in-line. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html