Bug report for Subversion 1.7.9

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
Received on 2013-05-24 15:02:23 CEST