On Tue, Apr 29, 2014 at 6:14 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Branko Čibej <brane_at_wandisco.com> writes:
>
>> We made a conscious decision
>> to design a working copy format that's faster than the old format could
>> ever have been and can better support new features (such as client-side
>> move tracking), at the expense of poorer performance on a remote
>> filesystem that is, when you get right down to it, a 30-year-old
>> dinosaur that was never designed for the kind of use that people these
>> days seem to assume it can support.
>
> The new working copy format in 1.7 had a speed issue with recursive
> commit on NFS but that has been fixed in later clients. Use 1.8 or 1.9
> and the new format is faster than the old format.
>
I'd like to add that, even though some developers may sound a bit
defensive in this mail-thread, nothing about performance is cast into
stone. It's not like there's an axiom saying "svn on Windows+NTFS has
to be 7 times slower than on Linux+ext4, period" or "svn on NFS or
CIFS has to be 20 times slower than on local disk".
These things are continually being worked on and improvements are made
regularly. And there remains plenty of room for discussions, new
thoughts, further research, profiling data that helps point out
potential areas to work on, or maybe even a patch (though I suspect
that most low-hanging fruit is already gone).
Trying to focus this thread back to its original subject of
Windows/NTFS performance (perhaps for NFS another thread should be
spun off), I've seen a couple of interesting questions that might
provide additional insight:
Ivan Zhakov <ivan_at_visualsvn.com> asked:
> Did you disable Antivirus or completely uninstalled? I'm asking
> because from my experience many antiviruses are still hooked in
> network stack even disabled. Only full uninstall helps.
>
> Also I recommend using '--quiet' for tests because even redirecting to
> $null can be slow in PowerShell.
>
> Also issue can be caused by different disk flush polices on Windows
> and Linux: could you try temporary turn off Windows write-cache buffer
> flushing on the device:
> http://blogs.msdn.com/b/oldnewthing/archive/2013/04/16/10411267.aspx
>
> I do not recommend this as solution, just to find root cause.
And Thorsten Schöning <tschoening_at_am-soft.de> asked:
> Guten Tag Florian Ludwig,
> am Mittwoch, 16. April 2014 um 19:13 schrieben Sie:
>
>> After disabling all those and running a test
>> checkout on Linux and Windows on the same machine I still get a
>> result of Linux being 7.3x times faster. Any ideas why?
>
> I may have missed them but some things to consider from my point of
> view are the following: NTFS always uses ACLs, ext4 surely won't and
> ACLs are more processing intensive than old style Posix permissions.
> Where did you store your working copy? Vista and Win 7 have changed
> the users directory structure by being backwards compatible using
> junctions. Depending on your checkout directory, resolving a junction
> may impact performance on each and every activity of your file system
> regarding the checkout, something which surely won't be the case under
> ext4 again because most of the users simply store in /home/xyz without
> any links involved. I may be wrong here but does Linux on NTFS still
> ignores ACLs as well? It surely did in earlier versions.
>
>> Client Machine
>> --------------
>
> How much RAM was provided for both OSes during the checkouts? How much
> was used for cache?
>
> Besides all that, a complete Process Monitor log for filesystem
> activity on Windows would surely be helpful, but a lot of work to
> properly research it of course.
These are quite interesting questions that might point to an
explanation for (part of) the difference.
Florian (or anyone), can you do additional experiments to help answer
some of these questions?
--
Johan
Received on 2014-04-30 02:28:29 CEST