Slow start-up on Git trees

Slow start-up on Git trees

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Hi,

Joakim Tjernlund reported in
http://bugs.gentoo.org/show_bug.cgi?id=281009 that Emacs started in a
Git tree is really slow.  This does not happen with other SCM systems
and we were able to reproduce the problem and narrowing it down
to /usr/bin/git diff-index -z HEAD -- Makefile, called in
vc-git-state.  Any possibilities to improve performance here?  Joakim
is cced, so you can ask him directly.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Slow start-up on Git trees

[Dan Nicolaescu]

Christian Faulhammer <fauli@gentoo.org> writes:

  > Hi,
  > 
  > Joakim Tjernlund reported in
  > http://bugs.gentoo.org/show_bug.cgi?id=281009 that Emacs started in a
  > Git tree is really slow.  This does not happen with other SCM systems
  > and we were able to reproduce the problem and narrowing it down
  > to /usr/bin/git diff-index -z HEAD -- Makefile, called in
  > vc-git-state.  Any possibilities to improve performance here?

There are at lease two ways: 
- talk the git people to improve the performance of "git diff-index",
- implement a vc-git-state-heuristic (see other vc-*-state-heuristic
  functions) that parses .git/index and uses that return the state of
  the file, thus avoiding the "git diff-index" call.

Is worth it?  
I'd say probably not, the delay only happens the first time of accessing
a file in the git tree.

Re: Slow start-up on Git trees

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

On Aug 19, 2009, at 4:56 PM, Dan Nicolaescu wrote:
> Is worth it?
> I'd say probably not, the delay only happens the first time of  
> accessing
> a file in the git tree.


I find the delays very annoying.

Can this not be called asynchronously?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Slow start-up on Git trees

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On Aug 19, 2009, at 4:56 PM, Dan Nicolaescu wrote:
  > > Is worth it?
  > > I'd say probably not, the delay only happens the first time of
  > > accessing
  > > a file in the git tree.
  > 
  > 
  > I find the delays very annoying.
  > 
  > Can this not be called asynchronously?

No, this is used to set the VC state for a file, which is needed as soon
as a user is able to issue commands.

Re: Slow start-up on Git trees

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hi,

Dan Nicolaescu <dann@ics.uci.edu>:

> Christian Faulhammer <fauli@gentoo.org> writes:
> 
>   > Hi,
>   > 
>   > Joakim Tjernlund reported in
>   > http://bugs.gentoo.org/show_bug.cgi?id=281009 that Emacs started
>   > in a Git tree is really slow.  This does not happen with other
>   > SCM systems and we were able to reproduce the problem and
>   > narrowing it down to /usr/bin/git diff-index -z HEAD -- Makefile,
>   > called in vc-git-state.  Any possibilities to improve performance
>   > here?
> 
> There are at lease two ways: 
> - talk the git people to improve the performance of "git diff-index",

 Which makes performance depending on the installed Git version.

> Is worth it?  
> I'd say probably not, the delay only happens the first time of
> accessing a file in the git tree.

 If it is annoying enough to generate a bug report on our tracker, it
is a problem.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Slow start-up on Git trees

[Joakim Tjernlund]

Dan Nicolaescu <dann@ics.uci.edu> wrote on 19/08/2009 22:56:00:
>
> Christian Faulhammer <fauli@gentoo.org> writes:
>
>   > Hi,
>   >
>   > Joakim Tjernlund reported in
>   > http://bugs.gentoo.org/show_bug.cgi?id=281009 that Emacs started in a
>   > Git tree is really slow.  This does not happen with other SCM systems
>   > and we were able to reproduce the problem and narrowing it down
>   > to /usr/bin/git diff-index -z HEAD -- Makefile, called in
>   > vc-git-state.  Any possibilities to improve performance here?
>
> There are at lease two ways:
> - talk the git people to improve the performance of "git diff-index",
> - implement a vc-git-state-heuristic (see other vc-*-state-heuristic
>   functions) that parses .git/index and uses that return the state of
>   the file, thus avoiding the "git diff-index" call.
>
> Is worth it?
> I'd say probably not, the delay only happens the first time of accessing
> a file in the git tree.

The first time every day is a bit annoying. How about, for a starter, a simple
way of disabling vc-git in ~/.emacs?

  Jocke

Re: Slow start-up on Git trees

[Dan Nicolaescu]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> wrote on 19/08/2009 22:56:00:
  > >
  > > Christian Faulhammer <fauli@gentoo.org> writes:
  > >
  > >   > Hi,
  > >   >
  > >   > Joakim Tjernlund reported in
  > >   > http://bugs.gentoo.org/show_bug.cgi?id=281009 that Emacs started in a
  > >   > Git tree is really slow.  This does not happen with other SCM systems
  > >   > and we were able to reproduce the problem and narrowing it down
  > >   > to /usr/bin/git diff-index -z HEAD -- Makefile, called in
  > >   > vc-git-state.  Any possibilities to improve performance here?
  > >
  > > There are at lease two ways:
  > > - talk the git people to improve the performance of "git diff-index",
  > > - implement a vc-git-state-heuristic (see other vc-*-state-heuristic
  > >   functions) that parses .git/index and uses that return the state of
  > >   the file, thus avoiding the "git diff-index" call.
  > >
  > > Is worth it?
  > > I'd say probably not, the delay only happens the first time of accessing
  > > a file in the git tree.
  > 
  > The first time every day is a bit annoying. How about, for a starter, a simple
  > way of disabling vc-git in ~/.emacs?

 (setq  vc-handled-backends                (delq 'Git vc-handled-backends))

Re: Slow start-up on Git trees

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Aug 19, 2009, at 5:11 PM, Dan Nicolaescu wrote:
>>
>> I find the delays very annoying.
>>
>> Can this not be called asynchronously?
>
> No, this is used to set the VC state for a file, which is needed as  
> soon
> as a user is able to issue commands.


Then use a semaphore.

In most cases the user will not issue a VC command, but work with the  
buffer.
That would also take care of annoyingly slow commits in CVS and other  
operations over the network.

I'm sure people must have thought of this at some point. But just in  
case doing all these time-consuming VC operations synchronously is due  
to the code being older than async process calls, I wanted to bring  
this up.

Wouldn't it be easier and less error-prone to use more async process  
calls than to wait for Lisp-level multithreading -?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Slow start-up on Git trees

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On Aug 19, 2009, at 5:11 PM, Dan Nicolaescu wrote:
  > >>
  > >> I find the delays very annoying.
  > >>
  > >> Can this not be called asynchronously?
  > >
  > > No, this is used to set the VC state for a file, which is needed as
  > > soon
  > > as a user is able to issue commands.
  > 
  > 
  > Then use a semaphore.
  > 
  > In most cases the user will not issue a VC command, but work with the
  > buffer.

I don't think it's worth it, so I have no interest in working on this,
but don't let that stop you from doing it.

  > That would also take care of annoyingly slow commits in CVS and other
  > operations over the network.
  > 
  > I'm sure people must have thought of this at some point. But just in
  > case doing all these time-consuming VC operations synchronously is due
  > to the code being older than async process calls, I wanted to bring
  > this up.

Doubtful.  VC operations that do not change state are asynchronous (it
they are not, it's likely a bug/oversight).
Would commit make sense to be asynchronous?  Hmm, maybe, but until
someone sits down and does it we won't know.
Unfortunately VC is one thing that a lot of people like to talk about,
but very few actually want to do any work on.

Re: Slow start-up on Git trees

[Stefan Monnier]

> I don't think it's worth it, so I have no interest in working on this,
> but don't let that stop you from doing it.

I think this part should definitely not be asynchronous: all it does is
try to figure out the state of a single file in terms of
"modified/unmodified/removed/added/...".  There is no reason why this
should take a long time.  So rather than make it asynchronous, I'd say
"make it faster".

> Would commit make sense to be asynchronous?  Hmm, maybe, but until
> someone sits down and does it we won't know.

Yes, it does make sense.  Actually most VCS operations should be
performed asynchronously.  So patches a very welcome in this part of VC
(PCL-CVS already does it all asynchronously, FWIW).


        Stefan