On Fri, Apr 25, 2014 at 11:10 AM, Roman Naumenko <ro...@naumenko.ca> wrote:
> > > ----- Original Message ----- > > On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard <markp...@gmail.com> > > wrote: > > > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig > > > <vierzigundz...@gmail.com> > > > wrote: > > > > > >> > > >> this topic was raised several times in the past - the answers > > >> range from > > >> "will be better/solved in the next version 1.7" or "it is due to > > >> ntfs vs > > >> ext3/4" or it's the AV, network setup or the Windows file indexing > > >> service. > > >> 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? > > > > > > > > > There are probably some good discussions about this in the archives > > > during > > > the run-up to 1.7 but my memories are fading. I do not think > > > anyone ever > > > said that the difference would be "solved" but more that the > > > architectural > > > changes in 1.7 were going to close the performance gap on Windows > > > when > > > compared to SVN 1.5/1.6 on Linux. There were a couple of big > > > performance > > > fixes backported to some the later 1.6.x releases so the "win" in > > > 1.7 is not > > > as great when compared with 1.6.latest as it is with 1.6.0. > > > > I remember this. The deadly operation was the initial checkout on > > network based file systems, especially CIFS on the Windows boxes. The > > few servers that ran NFS acted much more like Linux hosts, or like > > Linux hosts usin gNFS. A number of changes in Subversion, over time, > > reduced the perfidious chattiness that hampered CIFS baed checkouts, > > and all Windows users with network mounted working copies became > > *much* happier. > > > > Let's do be careful to draw distinctions between local file systems, > > like NTFS and ext4, and network file systems like CIFS and NFS. I'm > > afraid it's common to handwave those away as not making a difference, > > and they really do. > > Maybe windows users are happier (they are not), but Linux users are just > scratching their heads over svn performance. > > svn, version 1.7.8 (r1419691), standard redhat vm. > > NFS: > A benchmark-svn/trunk/notes/tree-conflicts/scratch-pad.txt > A benchmark-svn/trunk/notes/tree-conflicts/use-cases-resolution.txt > A benchmark-svn/trunk/notes/tree-conflicts/design-overview.txt > A benchmark-svn/trunk/notes/tree-conflicts/detection.txt > ^Csvn: E200015: Caught signal > > real 0m26.980s > user 0m0.454s > sys 0m1.281s > [11:02:30 user@host:~/svn_tests ] $ du -sh benchmark-svn > 12M benchmark-svn > > > Local: > A > /tmp/benchmark-svn/branches/1.6.x/subversion/libsvn_fs_base/bdb/reps-table.c > A > /tmp/benchmark-svn/branches/1.6.x/subversion/libsvn_fs_base/bdb/bdb_compat.h > ^Csvn: E200015: Caught signal > > real 0m13.241s > user 0m3.939s > sys 0m4.731s > [11:02:30 user@host:~/svn_tests ] $ du -sh /tmp/benchmark-svn > 144M /tmp/benchmark-svn > > What we've got here, 20x or something? > > That was a known consequence of moving to SQLite for storage of the metadata. SVN 1.8 offers a solution for those that can use it: http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking -- Thanks Mark Phippard http://markphip.blogspot.com/