git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Lars Schneider <larsxschneider@gmail.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	GIT Mailing-list <git@vger.kernel.org>,
	stephan.arens@autodesk.com
Subject: Re: Git super slow on Windows 7
Date: Wed, 25 Nov 2015 12:42:06 -0800	[thread overview]
Message-ID: <CAGZ79kYUor3Hx+ggaDvkc8MSH+nMtZrgGXRvgLz2qqHZmy5tCg@mail.gmail.com> (raw)
In-Reply-To: <CACsJy8Becrc57+56BCLSq8Pd9p5m2qpERqXwY2AN21H=BfADNA@mail.gmail.com>

On Wed, Nov 25, 2015 at 12:23 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Wed, Nov 25, 2015 at 7:47 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Wed, Nov 25, 2015 at 10:42 AM, Lars Schneider
>> <larsxschneider@gmail.com> wrote:
>>> After some investigation I figured that ~50 Submodules are the culprit.
>>> Does anyone have an idea how to speed up Git on Windows while keeping 50 Submodules?
>>>
>>> Thanks,
>>> Lars
>>>
>>>
>>
>> Use the latest version of Git ;)
>
> Does it do parallel refresh yet? I think it would help.  I only looked
> at "git log --merges origin/pu" and nothing caught my eyes.

No. The hinted patch series only does a partial shell->C conversion, which
is the best guess for improving git status here.

I punted on parallel local operations inside "git submodule update" for now, too
as when things go wrong there, you need a human to resolve the merge conflict,
and as a user you only want to deal with one merge conflict at a time instead of
being left there with a ton of unresolved issues (according to the git
log of older
patches in the submodule area).

git status should require not human interaction if things go bad
within submodules,
so we may want to speed that up by parallelizing the submodule part. The status
command gathers all information of submodules by a call to "git
submodule summary"
and does some slight post processing on the output. "git submodule
summary" however
is written completely in shell code (200 lines, so I estimate 400 lines of C).

I will benchmark that later today and check if it's worth for us to
rewrite that in C for
our case (we plan to have lots more submodules, but we're a linux shop)

      reply	other threads:[~2015-11-25 20:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 12:35 Git super slow on Windows 7 Lars Schneider
2015-11-25 18:42 ` Lars Schneider
2015-11-25 18:47   ` Stefan Beller
2015-11-25 20:23     ` Duy Nguyen
2015-11-25 20:42       ` Stefan Beller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGZ79kYUor3Hx+ggaDvkc8MSH+nMtZrgGXRvgLz2qqHZmy5tCg@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=larsxschneider@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=stephan.arens@autodesk.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).