some fs profiling of sorts.

I was interested in knowing just what kind of changes in performance
my implementation of the new node-rev-id schema had caused, so i did a
few timings running fs-test from /trunk and from /branches/issue-654-dev.

On the TRUNK version, fs-test was run like so:

   time fs-test 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 20 21 22 \
   24 26 27 28 29 30 31 33 34 35

and on BRANCH like so:

   time fs-test 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
   22 23 24 25 26 27 28 30 31 32

Note that both versions are missing the test that exercises
svn_fs_deltify() and svn_fs_undeltify() explicitly (because the BRANCH
version doesn't have this implemented yet). Additionally, the TRUNK
version skips tests 19, 23, and 25 which have been removed or disabled
in the BRANCH version because they simply don't apply anymore. I ran
each of the command lines above 4 times, dropped the lowest time for
each, and average the remaining three times.

    TRUNK: 46.66s
   BRANCH: 45.40s

Not a huge win with the BRANCH, but more importantly, not a lose! So
we have a filesystem that, at least in the tests we have (which don't
stress one big win of the new system -- the lack of a post-commit
stabilization walk), pretty much keeps the same pace, but doesn't have
node revision IDs that grow without bound.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:24:03 2002