Dear Subversion Team,
thank you for your effort in developing and constantly improving
Subversion.
We currently use Subversion 1.6.x for our application and are evaluating
the migration to 1.7 and 1.8.
While running our tests I have discovered a possible performance problem
in the 1.7/1.8 versions:
The problem is the _commit_ of a deleted file, i.e. the 'svn commit
<filename>' after a prior 'svn delete <filename>'.
For instance, imagine the following file tree already under full version
control:
dir
|
|- subdir
|- file.txt
Triggering 'svn delete file.txt' is fast. A subsequent 'svn commit
file.txt' ,however, takes much longer in 1.7+ in contrast to the 1.6.x
version.
I have performed some measurements using the following test
scenario/environment:
Environment:
* Intel i7 2.6Ghz cpu
* 8Gb RAM
* Windows 7 x64 Professional
* Oracle JDK 1.6u37
* Subversion 1.6.23 x86 vs. 1.7.10 x86 vs 1.8.0 x86 (all downloaded from Collabnet)
Scenario:
1) svnadmin create testrepo
2) svnserve --listen-host=localhost --listen-port=4444 --root=testrepo
3) svn co svn://localhost:4444/ wc
4) create file testXXX.html in <wc>
5) svn add wc/testXXX.html
6) svn commit wc/testXXX.html
7) svn delete wc/testXXX.html
8) svn commit wc/testXXX.html
The steps 4-8 in the scenario were repeated for 30 files. The time
needed for each operation was meaned over these 30 runs.
The eigth step is taking around 11 times longer in 1.7/1.8 compared to
1.6.x.
Here are my results:
Collabnet Subversion 1.6.23-1 32bit installer:
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 1.930.064 nanoseconds
add: 33.922.540 nanoseconds
commitadd: 94.885.332 nanoseconds
delete: 35.964.514 nanoseconds
commitdelete: 88.359.041 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Collabnet Subversion 1.7.10-1 32bit installer:
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 1,179,124 nanoseconds
add: 33,794,865 nanoseconds
commitadd: 91,458,958 nanoseconds
delete: 35,703,185 nanoseconds
commitdelete: 1,002,148,220 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Collabnet Subversion 1.8.0-2 32bit installer:
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 1,200,684 nanoseconds
add: 33,808,141 nanoseconds
commitadd: 97,393,487 nanoseconds
delete: 35,881,830 nanoseconds
commitdelete: 991,335,788 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
How to reproduce:
I assembled a little Java program that executes all steps above and can
be configured via command line. For each step it spawns a separate
process, which executes the corresponding task. This was done
intentionally to rule out JavaHL being a possible performance issue here
(fyi: the results via JavaHL are comparable to the ones listed above).
I attached the Java program in the zip file, which should be extracted
to a designated directory. Then open a command line, switch to the
directory and type something like:
java -cp benchmark.jar Benchmark -binPath "C:\Program Files (x86)\CollabNet\Subversion Client" -logFile "G:\temp\svnbenchmark_1.6.23-1.log" -repoPath "G:\temp\testrepo" -wcPath "G:\temp\wc"
The usage information will be displayed when executing the Benchmark
class without parameters, e.g.:
java -cp benchmark.jar Benchmark
java Benchmark [options...] arguments...
-binPath VAL : The path to the subversion binary directory
-deleteRepo : Whether the created repository should be deleted after the
test (default true).
-deleteWc : Whether the created working copy should be deleted after the
test (default true).
-logFile VAL : The path and name of the logFile which will be created. All
parent directories must exist.
-port N : The port on which the server should be started (default is
localhost:4444).
-repoPath VAL : The path of the repository which will be created. All parent
directories must exist.
-runs N : The number of runs for each operations (default 30).
-wcPath VAL : The path of the working copy which will be created. All parent
directories must exist.
I hope you will be able to reproduce the problem and may assist me in
solving it.
Thanks in advance for helping me out here.
Greets
Alexander Lüders
Received on 2013-07-29 19:38:10 CEST