FS commit comparisons

Okay, so I'm running some commit comparisons now. Below are the raw results
of the comparisons.

In all cases, the operation is over ra_local. The test is to 'svn add' a
single 25.6 meg file, then time/observe the commit of that file.
Specifically:

$ some-svn-client add file
$ some-svn-client commit -m "foo" file

The peak memory was observed by running a script in another window which did
"ps v $pid ; sleep 1" in a loop. I manually grabbed the peak info.

The add/commit was run twice, starting a fresh repository (created with an
svnadmin associated with the client under test). e.g. file1 was added in
rev1, and file2 in rev2.

---------------------------------------------------------------------------
Revision 1302 (0.9.0):

  Run 1:

    real 2m48.540s
    user 0m27.720s
    sys 0m2.650s

    Peak DRS/RSS: 96838 66200

  Run 2:

    real 1m50.657s
    user 0m27.660s
    sys 0m2.670s

    Peak DRS/RSS: 96838 67600

  Across both runs, total size of log files: 53,065,754
                 Size of 'strings' database: 51,576,832
---------------------------------------------------------------------------
Revision 1382 (the 4 meg buffering):

  Run 1:

    real 5m7.831s
    user 0m32.410s
    sys 0m10.300s

    Peak DRS/RSS: 48143 32776

  Run 2:

    real 4m1.383s
    user 0m32.040s
    sys 0m10.400s

    Peak DRS/RSS: 48143 41460

  Across both runs, total size of log files: 418,665,474
                 Size of 'strings' database: 51,576,832
---------------------------------------------------------------------------
Revision 1382 + dupkey patch:

  Run 1:

    real 1m13.882s
    user 0m27.130s
    sys 0m2.580s

    Peak DRS/RSS: 8491 5928

  Run 2:

    real 1m13.620s
    user 0m27.300s
    sys 0m2.310s

    Peak DRS/RSS: 8491 5932

  Across both runs, total size of log files: 53,107,573
                 Size of 'strings' database: 51,658,752
---------------------------------------------------------------------------

SUMMARY

         user sys DRS log
        ----- ----- --- ---
1302 27.69 2.66 97M 53M
1382 32.23 10.35 48M 419M
dupkey 27.22 2.45 8.5M 53M

Note that I avoid the "real" number, especially for the tests which had a
large resident set -- much of the real time was swapping stuff out :-) (and,
thus, the lower real time for the second run). The user/sys times are *very*
close for both runs, so we have a bit of reliability there. The DRS is
exactly the same on both runs, we we would hope to expect (the RSS is the
swapped-in portion, and depends a lot on system load; basically, we can
ignore it).

ANALYSIS

The numbers come out almost exactly as we would expect:

* 1302 and dupkey never append to a record. the former slams it all out at
  once, from memory, and the latter creates multiple records, rather than
  appending. Thus, their log sizes are equivalent.

* The user/sys times are probably correlated with the amount of disk I/O.
  1382's huge log files dominate the sys time.

* the DRS for 1302 is understandably huge: the whole file is kept in memory.
  I have no idea why 1382 was also huge. it is possible that a whole copy is
  kept in memory somewhere (BDB?).

* the dupkey patch appears to be Goodness(tm). it has equivalent speed as
  the original "all in memory" system, equivalent log file results, but an
  entire order of magnitude reduction in memory usage.

I'm going to clean up the patch a bit and commit sometime today or this
evening.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org