> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 19 februari 2010 12:03
> To: kmradke_at_rockwellcollins.com
> Cc: dev_at_subversion.apache.org
> Subject: Re: Is sqlite fast enough?
>
> kmradke_at_rockwellcollins.com writes:
>
> > 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.
Bert
Received on 2010-02-19 13:02:21 CET