> -----Original Message-----
> From: Alexander Lüders [mailto:alu_at_entimo.de]
> Sent: vrijdag 24 mei 2013 14:48
> To: users_at_subversion.apache.org
> Subject: 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)
With the Sqlite backend in 1.7+ every independent delete takes a constant
amount of time.
For Subversion 1.8 we optimized this code path and all the relevant queries
to avoid slowdowns in a few cases where sqlite would take a non optimized
one.
And on top of that we optimized for the case where you pass multiple deletes
via the api at once. (Not sure if that is mapped to JavaHL, but it probably
is)
I would recommend trying with the 1.8rc first as in a few weeks that will
the best supported version going forward. If this resolves your problem you
might be able to convince somebody to backport the most relevant changes to
1.7.
Bert
>
> 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-26 19:24:19 CEST