Re: [PATCH] rep-cache.db insert optimization (was: Re: [PATCH] svnadmin build-repcache command)

>
> We do have an extra call when a duplicate rep is attempted to be
> inserted into the rep-cache. When does that happen? I know it will
> happen when called from build-repcache; what other use-cases trigger the
> codepath you changed? Committing two files with equal contents
> sequentially doesn't call svn_fs_fs__set_rep_reference() at all for the
> second file.
>

I have spent some time examining when it happens and I see the following
cases:
1) Commit multiple files with the same content in one revision.
2) During commit, svn_fs_fs__set_rep_reference() is called for a property
    representation of each node, regardless of whether it is a duplicate or
not.
3) Commit a file with the same content as a property representation.

> What tests is this behaviour covered by?
>

I think that:
- Case 1) is for example covered by the rep_sharing_effectiveness() test.
- Case 2) is implicitly covered by various tests for versioned property
changes.
- Case 3) is not currently covered by a specific test, but the situation
seems to be
an edge case.

> What scenario does this bring a performance improvement in? What is the
> improvement, quantitatively?
>

I have compared the approaches with ‘FAIL’ and ‘IGNORE’ conflict resolution
algorithms using a synthetic benchmark. Inserting 10000 identical entries
into
a rep-cache.db which contains 250000 entries:

1) In the case of using the ‘FAIL’ algorithm: ~40000 microseconds.

2) In the case of using the ‘IGNORE’ algorithm: ~15000 microseconds.

Outside of the benchmark, there is ~15% improvement for the
‘build-repcache’ command.

Based on this, I assume that there are other commands that may benefit from
this change.

I have attached an updated patch.

Regards,

Denis Kovalchuk