git for windows slower than Git-1.9.5

[mkjo]

Hello,

I observed a performance difference in between the latest pre-release of git-for-windows and the "official" Windows version which is offered for download at git-scm.com.
Cloning a project with 100+ Submodules (yes, that's our repo structure, and for the certain use case, it really makes sense) takes up to 2x more time than in the 1.9.5 version. And the WIN 1.9.5 version is already 10x slower than a native linux implementation (e.g. fork in windows are a pain...)
Is this additional performance loss releated to the different approach of the msys2 implementation?
Is the performance difference already known?
Do you have any hints to play with, e.g. perfomance tuning options?

Thanks in advance for some tips or answers.

.jo

[dscho]

This is part duplicate of #32 and part a user question. Feel free to investigate on the #32 end, and as for user questions: we have this lovely mailing list (which is linked on the upper right of http://git-for-windows.github.io/) which is intended to host support and user questions. This issue tracker is really intended for bugs in our projects.

[dscho]

Having closed this as partial duplicate of #32, I still have to point out that Stefan Beller's work on making git submodule a builtin should also help matters. @mkjo whatever you can to support Stefan in that endeavor, I would recommend to do... e.g. reviewing or augmenting the patch series http://thread.gmane.org/gmane.comp.version-control.git/276111

[stefanbeller]

Yeah the git submodule is currently implemented as a shell script with embedded perl. And shell scripts do call programs all the time.

To completely derail the thread:
@mkjo How do you manage the 100 submodules? (i.e. does everyone need all of them or just a small subset? Or does everyone need around 80 of them and it's a pain to get all the right modules checked out?)

[mkjo]

First , let me say that after some config changing I observe no
performance degradation any more, it's about 10% faster for a clone.

Very good, I think the 2.5 release is it!
Thanks to all.

Yeah the |git submodule| is currently implemented as a shell script
with embedded perl. And shell scripts do call programs all the time.

I try to find time to participate on the refactoring of the submodule
handling. From my observation I've done recently, it's the repeated call
of sh and friends, made even worse with the virus scanner we have...

To completely derail the thread:
@mkjo https://github.com/mkjo How do you manage the 100 submodules?
(i.e. does everyone need all of them or just a small subset? Or does
everyone need around 80 of them and it's a pain to get all the right
modules checked out?)

I think the configuration approach we have choosen is not so common, but
really makes sense for us.
The project is a embedded device platform.
The 100+ Modules are in each project. In fact, we have about 200+ in a
pool.
Each submodule implements control algorithms, with it's own history and
branches. For each environment the embedded device runs in, we need to
re-order the submodule configuration to match the hardware around the
system.

We (I in fact :-) made a small C#-GUI which collects all the submodules
information into one place. This GUI shows the most important Info
(TAGs/Branches, dirty). All other actions are done with gitExtensions,
but started from our GUI. For example, for checking out the correct
Branch/Tag the gitExtensions checkout Revision command line is issued.

[dscho]

First , let me say that after some config changing I observe no performance degradation any more, it's about 10% faster for a clone.

Nice! May I ask what config changes you refer to?

[stefanbeller]

So for each new device you would create a new superproject to select the the right submodules?

[mkjo]

Am 20. August 2015 21:09:39 MESZ, schrieb dscho notifications@github.com:

First , let me say that after some config changing I observe no
performance degradation any more, it's about 10% faster for a clone.

Nice! May I ask what config changes you refer to?

Not 100% sure, but I did the 2.5 installation without the cache flag which is asked for during installation. The other thing is, that in our enterprise environment, home drives and home variables are on network shares by default.

[mkjo]

Am 20. August 2015 23:32:00 MESZ, schrieb Stefan Beller notifications@github.com:

So for each new device you would create a new superproject to select
the the right submodules?

Yes, exactly. Due to the need for referencing previous versions of some modules also, we cannot put the different module variants parallel on the directory tree.
Since the isolated history of a single module is also very important, subtree split/merge is also no option.