git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git svn show-ignore is excrutiatingly slow
@ 2009-10-28 17:43 Adam Spiers
  2009-10-30  6:39 ` Eric Wong
  0 siblings, 1 reply; 2+ messages in thread
From: Adam Spiers @ 2009-10-28 17:43 UTC (permalink / raw)
  To: git mailing list

Something is badly wrong here ...

$ cd $svn_wd
$ time svn propget -R svn:ignore >/dev/null
svn propget -R svn:ignore > /dev/null  0.28s user 0.20s system 98% cpu 0.490 total
$ cd $git_wd
$ time git svn show-ignore > show-ignore.out
git svn show-ignore > show-ignore.out  20.52s user 33.69s system 1% cpu 1:23:42.17 total

That's 10,000 times slower for what is effectively the same source
tree!  Admittedly the svn propget was a "warm" run and took longer the
first time around, but even so there are several orders of magnitude
difference.

I had a quick look at the code and it seemed to be doing the svn tree
recursion itself via Git::SVN::prop_walk(), which might explain why.
However I did not have time to dig deeper, so would welcome any ideas.

Thanks,
Adam

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: git svn show-ignore is excrutiatingly slow
  2009-10-28 17:43 git svn show-ignore is excrutiatingly slow Adam Spiers
@ 2009-10-30  6:39 ` Eric Wong
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Wong @ 2009-10-30  6:39 UTC (permalink / raw)
  To: Adam Spiers; +Cc: git mailing list

Adam Spiers <git@adamspiers.org> wrote:
> Mail-Followup-To: git mailing list <git@vger.kernel.org>

Hi Adam, MFT is frowned upon here.

> Something is badly wrong here ...
> 
> $ cd $svn_wd
> $ time svn propget -R svn:ignore >/dev/null
> svn propget -R svn:ignore > /dev/null  0.28s user 0.20s system 98% cpu 0.490 total
> $ cd $git_wd
> $ time git svn show-ignore > show-ignore.out
> git svn show-ignore > show-ignore.out  20.52s user 33.69s system 1% cpu 1:23:42.17 total
> 
> That's 10,000 times slower for what is effectively the same source
> tree!  Admittedly the svn propget was a "warm" run and took longer the
> first time around, but even so there are several orders of magnitude
> difference.

It's the difference between reading locally vs remotely.  git svn always
looks at the remote repository for this information.  In your example,
svn was looking at the working copy where it already has that
information in an easily accessible form.

Try running svn against your repository URL instead for a comparison:

  time svn propget -R svn:ignore $SVN_URL >/dev/null

> I had a quick look at the code and it seemed to be doing the svn tree
> recursion itself via Git::SVN::prop_walk(), which might explain why.
> However I did not have time to dig deeper, so would welcome any ideas.

It would be possible to reconstruct the information given untouched
copies of unhandled.log inside $GIT_DIR/svn/**.  On the other hand, it
does require running through the history of the project and I don't
think it's worth it for an operation that should be rarely needed.  I
designed the output of "git svn show-ignore" be stored in
$GIT_DIR/info/exclude

-- 
Eric Wong

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-10-30  6:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-28 17:43 git svn show-ignore is excrutiatingly slow Adam Spiers
2009-10-30  6:39 ` Eric Wong

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 NNTP newsgroup(s).