git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch] git svn slowness on win32
@ 2010-02-16 10:04 josh robb
  2010-02-16 10:34 ` Johannes Schindelin
  0 siblings, 1 reply; 3+ messages in thread
From: josh robb @ 2010-02-16 10:04 UTC (permalink / raw)
  To: git

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

Hi,

I'm using git svn (1.6.4.msysgit.0) within a WindowsXP VM running
under VMWare fusion on OSX 10.5. For me (and at least one other person
I know) git svn has been unbearably slow.

My profiling shows that almost all of the git-svn runtime is being
spent in DynaLoader (via SVN::Base::import) which I guess is slow in a
virtualized windows environment. For example:

$ time perl /libexec/git-core/git-svn rebase
Current branch master is up to date.

real 2m56.750s
user 0m3.129s
sys 2m39.232s

I've been able to make significant (an order of magnitude)
improvements to it's performance by delaying SVN::Base::import from
running until it's actually needed. After making this change:

$ time perl /libexec/git-core/git-svn rebase
Current branch master is up to date.

real 0m33.407s
user 0m1.409s
sys 0m23.054s

git svn rebase -n goes from 3m7.046s to 0m10.312s.

Would love to get some feedback/thoughts etc...

j.

[-- Attachment #2: git-svn.patch.txt --]
[-- Type: text/plain, Size: 990 bytes --]

--- git-svn.orig	Wed Jul 29 22:55:26 2009
+++ git-svn	Fri Dec  4 13:38:52 2009
@@ -27,11 +27,13 @@
 $| = 1; # unbuffer STDOUT
 
 sub fatal (@) { print STDERR "@_\n"; exit 1 }
-require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
-require SVN::Ra;
-require SVN::Delta;
-if ($SVN::Core::VERSION lt '1.1.0') {
-	fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
+sub _req_svn {
+	require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
+	require SVN::Ra;
+	require SVN::Delta;
+	if ($SVN::Core::VERSION lt '1.1.0') {
+		fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
+	}
 }
 my $can_compress = eval { require Compress::Zlib; 1};
 push @Git::SVN::Ra::ISA, 'SVN::Ra';
@@ -4379,6 +4381,8 @@
 	my ($class, $url) = @_;
 	$url =~ s!/+$!!;
 	return $RA if ($RA && $RA->{url} eq $url);
+
+	::_req_svn();
 
 	SVN::_Core::svn_config_ensure($config_dir, undef);
 	my ($baton, $callbacks) = SVN::Core::auth_open_helper(_auth_providers);

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

* Re: [patch] git svn slowness on win32
  2010-02-16 10:04 [patch] git svn slowness on win32 josh robb
@ 2010-02-16 10:34 ` Johannes Schindelin
  2010-02-17 23:15   ` Eric Wong
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Schindelin @ 2010-02-16 10:34 UTC (permalink / raw)
  To: josh robb; +Cc: git

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1453 bytes --]

Hi,

On Tue, 16 Feb 2010, josh robb wrote:

> I'm using git svn (1.6.4.msysgit.0) within a WindowsXP VM running
> under VMWare fusion on OSX 10.5. For me (and at least one other person
> I know) git svn has been unbearably slow.
> 
> My profiling shows that almost all of the git-svn runtime is being
> spent in DynaLoader (via SVN::Base::import) which I guess is slow in a
> virtualized windows environment. For example:
> 
> $ time perl /libexec/git-core/git-svn rebase
> Current branch master is up to date.
> 
> real 2m56.750s
> user 0m3.129s
> sys 2m39.232s
> 
> I've been able to make significant (an order of magnitude)
> improvements to it's performance by delaying SVN::Base::import from
> running until it's actually needed. After making this change:
> 
> $ time perl /libexec/git-core/git-svn rebase
> Current branch master is up to date.
> 
> real 0m33.407s
> user 0m1.409s
> sys 0m23.054s
> 
> git svn rebase -n goes from 3m7.046s to 0m10.312s.
> 
> Would love to get some feedback/thoughts etc...

How about the following commit message (trying to follow 
http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD):

-- snip --
git svn: delay importing SVN::Base until it is needed

Importing functions from a .dll into Git for Windows' perl is pretty slow,
so let's avoid importing if it is not necessary.

[... timing statistics here...]

Signed-off-by: Josh Robb <josh_robb@fastmail.fm>
-- snap --

Hmm?

Ciao,
Dscho

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

* Re: [patch] git svn slowness on win32
  2010-02-16 10:34 ` Johannes Schindelin
@ 2010-02-17 23:15   ` Eric Wong
  0 siblings, 0 replies; 3+ messages in thread
From: Eric Wong @ 2010-02-17 23:15 UTC (permalink / raw)
  To: josh robb; +Cc: git, Johannes Schindelin

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
> 
> On Tue, 16 Feb 2010, josh robb wrote:
> 
> > I'm using git svn (1.6.4.msysgit.0) within a WindowsXP VM running
> > under VMWare fusion on OSX 10.5. For me (and at least one other person
> > I know) git svn has been unbearably slow.
> > 
> > My profiling shows that almost all of the git-svn runtime is being
> > spent in DynaLoader (via SVN::Base::import) which I guess is slow in a
> > virtualized windows environment. For example:
> > 
> > $ time perl /libexec/git-core/git-svn rebase
> > Current branch master is up to date.
> > 
> > real 2m56.750s
> > user 0m3.129s
> > sys 2m39.232s
> > 
> > I've been able to make significant (an order of magnitude)
> > improvements to it's performance by delaying SVN::Base::import from
> > running until it's actually needed. After making this change:
> > 
> > $ time perl /libexec/git-core/git-svn rebase
> > Current branch master is up to date.
> > 
> > real 0m33.407s
> > user 0m1.409s
> > sys 0m23.054s
> > 
> > git svn rebase -n goes from 3m7.046s to 0m10.312s.
> > 
> > Would love to get some feedback/thoughts etc...
> 
> How about the following commit message (trying to follow 
> http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD):
> 
> -- snip --
> git svn: delay importing SVN::Base until it is needed
> 
> Importing functions from a .dll into Git for Windows' perl is pretty slow,
> so let's avoid importing if it is not necessary.
> 
> [... timing statistics here...]
> 
> Signed-off-by: Josh Robb <josh_robb@fastmail.fm>
> -- snap --

Hi Josh,

Your patch was missing a call to ::req_svn() in cmd_branch(), but
otherwise it appears fine and passes all tests.

Can you write a proper commit message + patch so we can apply
it cleanly as Johannes suggested?  Thanks!

(full diff below)

diff --git a/git-svn.perl b/git-svn.perl
index 473a0b9..224c29f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -36,11 +36,13 @@ $ENV{TZ} = 'UTC';
 $| = 1; # unbuffer STDOUT
 
 sub fatal (@) { print STDERR "@_\n"; exit 1 }
-require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
-require SVN::Ra;
-require SVN::Delta;
-if ($SVN::Core::VERSION lt '1.1.0') {
-	fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
+sub _req_svn {
+	require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
+	require SVN::Ra;
+	require SVN::Delta;
+	if ($SVN::Core::VERSION lt '1.1.0') {
+		fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
+	}
 }
 my $can_compress = eval { require Compress::Zlib; 1};
 push @Git::SVN::Ra::ISA, 'SVN::Ra';
@@ -730,6 +732,7 @@ sub cmd_branch {
 		$src=~s/^http:/https:/;
 	}
 
+	::_req_svn();
 	my $ctx = SVN::Client->new(
 		auth    => Git::SVN::Ra::_auth_providers(),
 		log_msg => sub {
@@ -4859,6 +4862,8 @@ sub new {
 	$url =~ s!/+$!!;
 	return $RA if ($RA && $RA->{url} eq $url);
 
+	::_req_svn();
+
 	SVN::_Core::svn_config_ensure($config_dir, undef);
 	my ($baton, $callbacks) = SVN::Core::auth_open_helper(_auth_providers);
 	my $config = SVN::Core::config_get_config($config_dir);

-- 
Eric Wong

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

end of thread, other threads:[~2010-02-17 23:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-16 10:04 [patch] git svn slowness on win32 josh robb
2010-02-16 10:34 ` Johannes Schindelin
2010-02-17 23:15   ` 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).