[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Subversion/Perforce timing statistics

From: Joshua Jensen <jjensen_at_workspacewhiz.com>
Date: 2002-05-25 19:10:09 CEST

> Perforce stores the depot files in a database on the server.
> The client's working copy is stored directly to their disk,
> with no meta information. Perforce has no control over the
> file system operations performed on the client. In fact, you
> could do "p4 sync" followed by "rm -rf *" followed by "p4
> have" and Perforce will happily tell you that you have all of
> the latest changes. Perforce pays no attention at all to the
> contents of your wc. It knows what you are up to only because
> you explicitly told it so. This makes it incredibly fast at
> operations such as "p4 opened", "p4 have", and "p4 sync".

Yes, this is how Perforce works. The whole point of the exercise was to
contrast the speed difference. My upcoming tests will be to drop 10x as
many files into the repository. Then I'll test 100x as many files. My
guess will be that Perforce's numbers won't change much, just due to the
fact that the server keeps track of the information. Subversion's,
however, I expect to scale in the some linear percentage of the 10x or
100x amount of files.

I mean, svn status is performed entirely local. That's fine, although
it's at the expense of twice as much hard drive space (a point that will
concern many people, including myself). But due to the nature that
everything is checked out all the time, svn status would have no choice
(in my opinion, and I haven't looked that code) than to check time
stamps on every single file.

Either way, it still doesn't explain the MASSIVE variance in time for
the imports of the two directories into either system. Note that both
operations were performed entirely local. Subversion felt like it was
on a slow modem connection. Frankly, even Perforce was slow compared to
the split section 'xcopy' operation it took to move the directory to a
location I could deal with it at.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 25 19:11:51 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.