Repository navigation
git for windows slower than Git-1.9.5 #270
Description
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
Activity
dscho commentedon Aug 11, 2015
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 commentedon Aug 19, 2015
Having closed this as partial duplicate of #32, I still have to point out that Stefan Beller's work on making
git submodulea 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/276111stefanbeller commentedon Aug 19, 2015
Yeah the
git submoduleis 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 commentedon Aug 19, 2015
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.
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...
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 commentedon Aug 20, 2015
Nice! May I ask what config changes you refer to?
stefanbeller commentedon Aug 20, 2015
So for each new device you would create a new superproject to select the the right submodules?
mkjo commentedon Aug 21, 2015
Am 20. August 2015 21:09:39 MESZ, schrieb dscho [email protected]:
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 commentedon Aug 21, 2015
Am 20. August 2015 23:32:00 MESZ, schrieb Stefan Beller [email protected]:
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.
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status
Merge updates to serialized status