On Fri, Feb 6, 2009 at 10:37 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Fri, Feb 6, 2009 at 4:28 PM, Ruslan Sivak <russ_at_vshift.com> wrote:
>> Toby Thain wrote:
>>>
>>> Switch to Linux or OS X, which should be good for an immediate 10-20x
>>> speedup.
>>>
>>> --Toby
>>
>> Do you have any benchmarks to back this up?
>
> This isn't really Windows-bashing. The way SVN uses the local
> filesystem is just orders of magnitude faster on Linux and OSX. Here
> is a recent thread:
>
> http://svn.haxx.se/users/archive-2009-01/0326.shtml
>
> Back when I used to work on Windows, I would sometimes fire up Linux
> in VMWare to test some Subclipse feature in Linux. The performance of
> Eclipse/SVN in that Linux VM blew away Windows running natively as the
> host. The performance difference is frankly shocking.
I think this is really is 'Windows bashing' unless you have explicit
numbers to prove it isn't.
Just saying NTFS is slow because subversion is slow on it doesn't
prove anything. I already showed that our abuse of the wrong APR apis
made merging twice as slow as it should be on Windows.
The NTFS filesystem is a pretty fast filesystem, but it is case
insensive. (Thats what the independent tests are saying).
NTFS is a journaling filesystem with true AccessControl Lists instead
of uuid/gid/mask numbers that can only map a few security settings.
APR and Subversion were designed for case insensitive filesystems and
the uid/gid/mask mapping and both apr and subversions have their own
compatibility systems that try to make Subversion
case-insensitive-aware and look like a uuid/gid/mask system.
(This is also partly the case on the mac but most issues were solved
in another way there).
In most cases this making the filesystem unix like is the real pain we see.
And I already removed a few of these major performance killers in the
later 1.5.X releases. (Just compare the speed of a file:/// repository
merge with 1.5.0 and 1.5.5)
In the case of Eclipse it could be that Eclipse and/or javahl are
still using the same slow APIs Subversion stopped using, or that some
of the Java apis have the same assumptions. (But let's assume SUN
fixed the most painful performance issues).
I know the commandline does a true name check on all of its arguments
and GUIs usually pass far more arguments to the lower layers.
Another thing I found out while performance testing is that the
Console Windows are pretty slow in showing large amounts of texts. In
many cases the applications are waiting for this text to show on
screen before continuing, while on unix this will not hold the
application. (I would recommend catting the output to a file in
performance tests)
BTW. TortoiseSVN's listviews have the same performance killing
design... AnkhSVN 2.0 uses a second thread to make sure we never have
to wait for the screen to repaint...
Even on a single core system this improves performance, because it can
now repaint the screen while waiting for network IO.
But please, if you can: show us where other performance issues are so
we can fix them.
Bert
> I've been fortunate enough to be able to work on OSX the last two
> years so those differences are mostly just a memory now.
>
> If this is an option, it is worth trying. I think when SVN 1.7 rolls
> around the differences in performance will be narrowed significantly
> but Linux is likely to always be faster because its filesystems are
> just generally faster than NTFS.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1115334
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-07 00:49:49 CET