On Fri, Apr 25, 2014 at 11:10 AM, Roman Naumenko <roman_at_naumenko.ca> wrote:
>
>
> ----- Original Message -----
> > On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard <markphip_at_gmail.com>
> > wrote:
> > > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
> > > <vierzigundzwei_at_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_at_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_at_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/
Received on 2014-04-25 17:14:45 CEST