git status is slow git-status is fast.

[govind...@gmail.com]

Hi Folks,

I was just playing around with msys git, I think I will end up using
it for my pilot project in my company since it is so easy to install.
I noticed that if I run "git status" it takes several seconds on a
fairly small repo, but if I run git-status is is decently fast. Here
are my timings:

$ time git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitignore
# <about 12 files here>
#

real 0m5.422s
user 0m0.015s
sys 0m0.015s

$ time git-status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitignore
# <same list of files>
#

real 0m0.734s
user 0m0.227s
sys 0m0.106s

I know how performance centric git is, so I thought I would bring this
to your attention.

Apologies if this has been brought up before.

Thanks,
Govind.

[Torgil Svensson]

On Aug 12, 9:09 pm, govindsali...@gmail.com wrote:

> $ time git status
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: .gitignore
> # <about 12 files here>
> #
>
> real 0m5.422s
> user 0m0.015s
> sys 0m0.015s
>
> $ time git-status
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: .gitignore
> # <same list of files>
> #
>
> real 0m0.734s
> user 0m0.227s
> sys 0m0.106s

I don't see that here. I only see differences between cold and hot
cache. What if you run "git status" two times in a row?

//Torgil

[govind...@gmail.com]

Yeah, I have tried doing it several times in a row with no change. I
also see the same thing with git-commit vs "git commit" and a couple
of
other commands. Somehow the git uber script is causing the system to
sit there for a while before doing anything (disk doesn't light up for
a couple of seconds).

Here are 4 consecutive runs

$ time git checkout master
Switched to branch "master"

real 0m5.484s
user 0m0.015s
sys 0m0.000s

$ time git checkout testbranch
Switched to branch "testbranch"

real 0m5.718s
user 0m0.030s
sys 0m0.000s

$ time git-checkout master
Switched to branch "master"

real 0m0.797s
user 0m0.470s
sys 0m0.167s

$ time git-checkout testbranch
Switched to branch "testbranch"

real 0m0.812s
user 0m0.454s
sys 0m0.243s

I just ran GitMe today.

$ git version
git version 1.5.3.GIT

HTH.

Thanks,
Govind.

[govind...@gmail.com]

Actually, forget it. I just tried this on another system and it seems
to be ok. I have a lot of security software on my 1st system (company
laptop) and I bet that is what is causing the problem.

False alarm, sorry.
Govind.

[Johannes Schindelin]

Hi,

On Sun, 12 Aug 2007, govind...@gmail.com wrote:

> Actually, forget it. I just tried this on another system and it seems
> to be ok. I have a lot of security software on my 1st system (company
> laptop) and I bet that is what is causing the problem.

I almost thought that you might call cygwin's git-status with one call...

Could you trace with "GIT_TRACE=/trace.out" where the issues lie? It
might be fixable.

Ciao,
Dscho

[Dmitry Kakurin]

I have a similar problem. All the time is spent in launching new app.
Not sure why though.
--
- Dmitry

[Govind Salinas]

result of "git status"

trace: exec: 'C:/msysgit/bin/git-status'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--is-inside-work-tree'
trace: built-in: git 'rev-parse' '--is-inside-git-dir'
trace: built-in: git 'rev-parse' '--verify' 'HEAD'
trace: built-in: git 'update-index' '-q' '--unmerged' '--refresh'
trace: built-in: git 'runstatus'

result of git-status

trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--is-inside-work-tree'
trace: built-in: git 'rev-parse' '--is-inside-git-dir'
trace: built-in: git 'rev-parse' '--verify' 'HEAD'
trace: built-in: git 'update-index' '-q' '--unmerged' '--refresh'
trace: built-in: git 'runstatus'

Is there a way to get trace to print with timestamps?

FYI, I had uninstalled Cygwin git, so my original runs could not have
run them by accident. I have since reinstalled it to see if I could
get gitweb to work (and I can't).

Also, my experience seems to be the same as the Dmitry, it does
nothing for a couple seconds while trying to launch git-status, then
git-status runs quickly.

Thanks,
Govind.

[Johannes Schindelin]

Hi,

On Mon, 13 Aug 2007, Dmitry Kakurin wrote:

> I have a similar problem. All the time is spent in launching new app.
> Not sure why though.

Do I understand correctly that the issue is that "git status" is slower
than "git-status"?

In that case, we should profile the issue. Unfortunately, there does not
seem to exist something like oprofile, so we'll have to roll our own.

Ciao,
Dscho

[Govind Salinas]

Forgot to sent to the list.

---------- Forwarded message ----------
From: Govind Salinas <govind...@gmail.com>
Date: Aug 13, 2007 11:34 AM
Subject: Re: [msysGit] Re: git status is slow git-status is fast.
To: Johannes Schindelin <Johannes....@gmx.de>

More food for thought, here is cygwin's git timings (built using a
pull from a few days ago)

$ time git status > /dev/null

real 0m1.638s
user 0m0.613s
sys 0m1.165s

$ time git-status > /dev/null

real 0m1.639s
user 0m0.614s
sys 0m1.074s

this is using git version 1.5.3.rc4.29.g74276

The git that ships with cygwin shows slightly higher numbers, but
still consistent. (I've been reading the list and know there have
been some performance improvements recently).

$ time /bin/git status > /dev/null

real 0m2.098s
user 0m0.816s
sys 0m1.446s

$ time /bin/git-status > /dev/null

real 0m2.077s
user 0m0.694s
sys 0m1.494s

this is git version 1.5.2.2

For some reason mingw/msys git and cygwin git have a disagreement
about weather the files are changed or not. I had chalked this up to
the fact that they are different versions, I think one things they
should have crlf and one thinks otherwise. (I have core.autocrlf set
to false because true was causing problems for me)

On 8/13/07, Johannes Schindelin <Johannes....@gmx.de> wrote:

[Johannes Schindelin]

Hi,

On Mon, 13 Aug 2007, Govind Salinas wrote:

> More food for thought, here is cygwin's git timings (built using a
> pull from a few days ago)
>
> $ time git status > /dev/null
>
> real 0m1.638s
> user 0m0.613s
> sys 0m1.165s
>
> $ time git-status > /dev/null
>
> real 0m1.639s
> user 0m0.614s
> sys 0m1.074s

This basically means that the slow down is probably to be found in the
MinGW specific patches to git.c or exec_cmd.c. Will have a look later
(but I'll be off the internet before that, I fear).

> For some reason mingw/msys git and cygwin git have a disagreement
> about weather the files are changed or not.

"Some reason" is that the index uses stat() data. However, cygwin gives a
more complete, UNIXy emulation of stat(). For example, it emulates
symlinks by .lnk files.

So there is nothing you can do there, except run "git status" after
switching from MinGW to cygwin git or vice versa.

I also do not see a point for changing this behaviour: the changes would
be pretty painful, and there should not be a reason to use cygwin _and_
MinGW Git on the same repo.

Ciao,
Dscho

[Govind Salinas]

Dammit, I did it again.

---------- Forwarded message ----------
From: Govind Salinas <govind...@gmail.com>
Date: Aug 13, 2007 12:04 PM
Subject: Re: [msysGit] Fwd: [msysGit] Re: git status is slow git-status is fast.
To: Johannes Schindelin <Johannes....@gmx.de>

On 8/13/07, Johannes Schindelin <Johannes....@gmx.de> wrote:

> Hi,
>
> On Mon, 13 Aug 2007, Govind Salinas wrote:
> >
> > For some reason mingw/msys git and cygwin git have a disagreement
> > about weather the files are changed or not.
>
> "Some reason" is that the index uses stat() data. However, cygwin gives a
> more complete, UNIXy emulation of stat(). For example, it emulates
> symlinks by .lnk files.
>
> So there is nothing you can do there, except run "git status" after
> switching from MinGW to cygwin git or vice versa.
>

After running "git status" or "git-update-index --refresh" multiple
times it is still reporting them as needing update. Running "git
diff" tells me that it wants to rewrite the entire contents of every
file. If I run "git diff --ignore-space-at-eol" then every file has a
mode change, apparently to 100644. So it seems to be more than a
dirty cache. I am not too concerned about being able to look at a
repo using both cygwin git an mingw git in the long run, hopefully I
will be able to settle down with one soon.

> Ciao,
> Dscho
>
>

[Dmitry Kakurin]

On 8/13/07, Govind Salinas <govind...@gmail.com> wrote:
> After running "git status" or "git-update-index --refresh" multiple
> times it is still reporting them as needing update. Running "git
> diff" tells me that it wants to rewrite the entire contents of every
> file. If I run "git diff --ignore-space-at-eol" then every file has a
> mode change, apparently to 100644. So it seems to be more than a
> dirty cache. I am not too concerned about being able to look at a
> repo using both cygwin git an mingw git in the long run, hopefully I
> will be able to settle down with one soon.

You should have core.filemode=false if you use mingw port.

--
- Dmitry

[Johannes Schindelin]

Hi,

On Mon, 13 Aug 2007, Govind Salinas wrote:

> After running "git status" or "git-update-index --refresh" multiple
> times it is still reporting them as needing update. Running "git diff"
> tells me that it wants to rewrite the entire contents of every file.
> If I run "git diff --ignore-space-at-eol" then every file has a mode
> change, apparently to 100644.

MinGW does not have the option to mark files as executable with chmod. If
they end in .exe, .bat or .cmd, or if their first line starts with '#!',
they are assumed to be executable AFAIK.

Ciao,
Dscho