Re: svn commit: rev 7695 - in trunk: doc/book subversion/include subversion/libsvn_fs subversion/libsvn_repos subversion/svnadmin subversion/tests/libsvn_fs

Greg Stein <gstein@lyra.org> writes:

> On Mon, Nov 10, 2003 at 07:01:20PM -0600, cmpilato@tigris.org wrote:
>>...
>> +++ trunk/subversion/svnadmin/main.c Mon Nov 10 19:01:18 2003
>>...
>> +/* This implements `svn_opt_subcommand_t'. */
>> +static svn_error_t *
>> +subcommand_deltify (apr_getopt_t *os, void *baton, apr_pool_t *pool)
>> +{
>>...
>> + /* Loop over the requested revision range, performing the
>> + predecessor deltification on paths changed in each. */
>> + increment = (start > end) ? -1 : 1;
>> + end = end + increment;
>> + for (revision = start; revision != end; revision += increment)
>> + {
>
> Is there an "optimum" direction for the deltification? If so, then I'd
> recommend reordering these to ensure they go in the best order.
>
> For example, if deltify r1000 requires creating of a fulltext of r999,
> then you'd want to do 1000 *before* deltifying 999.

Using this repository

   stress.pl -c -s0 -F10 -D10 -N2 -x100 -W -d -P3 -n40

(that's 40 revisions, 100 files per revision, a small change in each
30k file) and comparing

   svnadmin deltify -r1:41 repostress
   svnadmin deltify -r41:4 repostress

I find that forward is faster than backward, i.e. 41:1 takes about 50%
more CPU than 1:41.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org