Perforce outperforms Subversion (by a lot sometimes)

[James McNeill <ja...@suckerpunch.com>]

I've been doing benchmarks and testing on Subversion and Perforce to compare
them.  In my tests Perforce has been consistently at least 2-4 times as fast
as Subversion, and sometimes much, much more than that.  I've tried
Subversion access via both the http and svn ports; I didn't notice much
difference between the two.

 

On a repository with about 5 GB in 25,000 files, my first 'svn update' at
the root (with nothing needing updating) after booting the client machine
took 53 seconds in one test, 71 seconds in another.  Subsequent updates took
2-3 seconds.  A 'p4 sync' command at the root of the Perforce version of the
repository (again, with no updates needed) takes <1 second, every time.

 

My guess is that, since Perforce maintains a model of the client state on
the server, it doesn't have to do much of anything to figure out that
nothing needs to be done.  Based on Subversion's timings I would guess that
it's having to page large amounts of the client's disk into memory to figure
out that no action is required.

 

This sort of thing really drags down the user experience on Subversion.  Are
there any plans to maintain models of client state server-side, or is that
straying too far from the Subversion Way?  Are there any ideas about how to
bring Subversion's performance more in line with Perforce's?  This (along
with merge tracking, which I see is slated for fixing) is the main thing
that makes me hesitate to recommend Subversion for use at my company.

 

James McNeill

 

Re: Perforce outperforms Subversion (by a lot sometimes)

[Russ Brown <pi...@gmail.com>]

James McNeill wrote:
> I’ve been doing benchmarks and testing on Subversion and Perforce to 
> compare them.  In my tests Perforce has been consistently at least 2-4 
> times as fast as Subversion, and sometimes much, much more than that.  
> I’ve tried Subversion access via both the http and svn ports; I didn’t 
> notice much difference between the two.
> 
>  
> 
> On a repository with about 5 GB in 25,000 files, my first ‘svn update’ 
> at the root (with nothing needing updating) after booting the client 
> machine took 53 seconds in one test, 71 seconds in another.  Subsequent 
> updates took 2-3 seconds.  A ‘p4 sync’ command at the root of the 
> Perforce version of the repository (again, with no updates needed) takes 
> <1 second, every time.
> 
>  
>  
> 

I'd be interested to see what result you get when using SVK as a 
Subversion client instead of svn. That's what we do and find it to be 
much quicker for most if not all operations.

-- 

Russ

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Perforce outperforms Subversion (by a lot sometimes)

[kf...@collab.net]

Ben Collins-Sussman <su...@collab.net> writes:
> They're totally different design philosophies.  Perforce is designed
> for a LAN, and the server happily tracks every sandbox of every
> developer.  CVS and Subversion are designed for the WAN... lots of
> disconnected work happening, and a potentially unlimited number of
> self-sustaining sandboxes.  (Which is why it's so good for open-
> source work -- and anonymous checkouts.)
> 
> I don't think Subversion has any goals of changing its design
> philosophy here...

Yes.  Obviously, we're always interested in making Subversion faster,
but tracking client-side state on the server would be wandering pretty
far from Subversion's basic design.  We should find other ways to do
it.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Perforce outperforms Subversion (by a lot sometimes)

[Ben Collins-Sussman <su...@collab.net>]

On Sep 16, 2005, at 7:02 PM, James McNeill wrote:

> This sort of thing really drags down the user experience on  
> Subversion.  Are there any plans to maintain models of client state  
> server-side, or is that straying too far from theSubversion Way?

They're totally different design philosophies.  Perforce is designed  
for a LAN, and the server happily tracks every sandbox of every  
developer.  CVS and Subversion are designed for the WAN... lots of  
disconnected work happening, and a potentially unlimited number of  
self-sustaining sandboxes.  (Which is why it's so good for open- 
source work -- and anonymous checkouts.)

I don't think Subversion has any goals of changing its design  
philosophy here...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org