Am 18.07.2014 15:02, schrieb Fredrik Gustafsson:
> On Fri, Jul 18, 2014 at 02:08:36PM +0200, Thomas Braun wrote:
>> Am 18.07.2014 12:14, schrieb Armbruster Joachim (BEG/EMS1):
>>> We split a monolithic repository into ~50 submodules. The stored data
>>> has the same size. In the 1:1 comparison to the monolithic
>>> repository, the submodule handling is very slow. Under Linux
>>> everything remains fast, but windows is slow.
>>> So, why is git getting slow when it has to deal with a lot of
>>> submodules? I read something about the lack of the underlying cygwin
>>> to handle NTFS in a efficient way. Is this the root cause, or are
>>> there other causes also?
>> I assume you are using the latetst git from https://msysgit.github.io on
>> I would guess that submodules on windows are slow because
>> git-submodules.sh is a shell script, and bash on windows is not really
>> that fast.
> My guess is that because the shell script uses fork() heavily and fork()
> is an expensive operation on Windows, that alone causes the slowddown.
> I did a quick test a while back when I rewrote part of git-submodule.sh
> in lua and runned it on my repo with ~45 submodules. The speedup was
> significant and should be even bigger on windows.
Without having looked at your Lua rewrite I suspect my recursive
submodule checkout series could speed that up even more, as it
only needs to fork a "git status" followed by a "git checkout" or
"git read-tree" for each submodule. Now that my submodule test
harness and Heiko's submodule config lookup API did hit next,
this is the thing I'm currently working on.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html