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

Reply via email to