> > > What platform were these test executed on? We need to make sure
> > > windows platforms are just as zippy.
> >
> > I tested on Debian stable. I don't currently build on Windows, but
> > all the code I used is in my first email so you should be able to
> > reproduce it if you want. I do have a VM running XP so perhaps I
> > should learn how to do a Windows build.
> >
> > Much in the same way that we have been assuming that sqlite will
> > perform acceptably, we have been assuming that it will perform
> > acceptably on Windows. Subversion has always had less performance on
> > Windows because of the way it interacts with the filesystem and I
> > think the assumption is that Windows might see a bigger performance
> > gain than Unix. Running the sort of tests I ran would be a good thing
> > to do.
>
> I can confirm that I see a much bigger performance improvement on
Windows
> than the other developers are reporting on other operating systems. This
is
> mostly related to using fewer files for the same operations. (Creating
files
> on a journaling filesystem is much slower than on systems without a
journal.
> And Windows does full journaling on creating empty or small files).
>
> Write/read performance inside a single file (read: database) is much
more
> comparable between operating systems as most filesystems and operating
> systems optimize for this case. (NTFS isn't particularly optimized for
> creating thousands of empty files and then deleting them a few seconds
> later, but it is a fast filesystem for e.g. large databases and huge
media
> files).
>
> Another slowdown commonly experienced with Subversion 1.0-1.6 on Windows
is
> that some files are locked by virusscanners/indexers/other subversion
> clients monitoring the same files. The Subversion libraries then have to
> perform some wait loop.
> Switching to a central database file that isn't deleted/replaced after
every
> operation allows better concurrent access for these tools. So you should
> also see fewer delays here.
Good to hear. I know the TortoiseSVN devs are not using the dev svn
branch
currently because of the previous huge performance issues they saw in
the past. Sounds like it might be time to get them to try again. I
know they monitor this list. (Unfortunately I'm not setup to do windows
builds either, or I would have just tested instead of asking...)
Kevin R.
Received on 2010-02-19 15:44:11 CET