Dear Subversion support team,
I want to file a bug report affecting Subversion 1.7.9.
In our software system, we currently use Subversion 1.6 and recognized a
possible performance reduction (~ 15x times) in 1.7 concerning the deletion of
files using JavaHL.
Let's start describing test environment + scenario:
Environment:
* Intel i7 2.6Ghz cpu
* 8Gb RAM
* Windows 7 x64 Professional
* Oracle JDK 1.6u37
* Subversion 1.6.21 x32 vs. 1.7.9 x32 (both downloaded from Collabnet)
Scenario:
I started setting up a local empty repository with full anonymous access.
svnadmin create repo --fs-type fsfs
Then I started two consecutive test runs, one time using 1.6.21, the other
1.7.9. Each run involved three steps:
1) starting local server: svnserve.exe -d --listen-host localhost --listen-port
4444 -r testrepo
2) checking out local working copy
3) running Java test program, which uses JavaHL to access the repository via
SVN URL
The Java test program basically consists of 5 steps.
1) Copying N testfiles to the root of the working copy (N sequential copy
operations).
2) Adding these N testfiles (N sequential add operations)
3) Committing these N testfiles (N sequential commit operations)
4) Deleting these N testfiles (N sequential delete operations)
5) Committing the deletion of the N testfiles (N sequential commit operations)
Each test was run with N = 50, i.e. I had 50 sequential copy, followed by 50
add, commit, delete and again commit operations.
The two Java test programs had only minor modifications to account for the
minor changes in the JavaHL Bindings in 1.6 and 1.7., respectively.
The calls to 'svn add', 'svn commit' and 'svn delete' were using the same
parameters, which will subsequently be listed for completeness:
add:
path = absolute filePath
depth = Depth.empty
force = false
noIgnores = false
makeParents = false
commit:
paths = array/set with single path
depth = Depth.empty
noUnlock = false
keepChangeLists = false
changeLists = null
revPropTable = null
delete:
path = array/set with single path pointing to the file to be deleted (1.6) /
deleted file (1.7)
force = true
keepLocal = false
revProp = null
commitCallback = null
The measurement was performed internally for each step using
System.nanoseconds(). It represents the accumulated time for the specified step
for the N runs.
These were the results:
Collabnet svn, version 1.6.21 (r1462351), N=50:
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 55,678,140 nanoseconds
add: 323,881,044 nanoseconds
commitadd: 2,986,280,688 nanoseconds
delete: 452,160,586 nanoseconds
commitdelete: 3,262,215,833 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
svn, version 1.7.9 (r1462340)
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 58,092,656 nanoseconds
add: 332,664,285 nanoseconds
commitadd: 3,208,830,490 nanoseconds
delete: 336,923,540 nanoseconds
commitdelete: 49,467,846,354 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I can only speculate about the huge performance difference concerning the
commit of the deleted file. There might be a connection with 1.7. removing the
file immediately after a call to 'svn delete'.
Maybe a subsequent commit specifying a path to a file, which does not exist any
more, results in additional lookup time during the commit operation.
At the moment this issue is preventing us from migrating to Subversion 1.7. Do
you know if this issue can be fixed timely (or is already fixed in 1.8)?
P.S.: If interested I'm happy to deliver the Java sources.
Thanks in advance
Alexander Lüders
