Re: Potential regression: high server-side memory consumption during import

Philip Martin <philip_at_codematters.co.uk> writes:

> Note an odd effect in the above numbers. The second run for 1.11 is
> always the fastest. The first run in each case is the slowest, the
> Subversion cache is cold. The second run is faster, the Subversion
> cache is hot. In 1.9 subsequent runs are comparable to the second, but
> in 1.11 the subsequent runs are a bit slower than the second. I don't
> know what causes this effect.

This is a cache size effect. The early runs can write to the cache
without having to evict, later runs can only write if they first evict.
I happened to choose a cache size that allowed the first two runs to do
very little eviction, the third and subsequent runs need to evict more.
If I make the cache bigger I can postpone the eviction and the third run
becomes as fast as the second.

Here are the cache stats before/after a run once the timing has
stabilised:

gets : 11770766, 4388248 hits (37.28%)
sets : 7309448 (99.01% of misses)
failures: 0
used : 777 MB (94.56%) of 822 MB data cache / 958 MB total cache memory
2225228 entries (99.45%) of 2237592 total
58607 buckets with 7 entries
64670 buckets with 6 entries
58592 buckets with 5 entries
48780 buckets with 4 entries
38212 buckets with 3 entries
27996 buckets with 2 entries
22422 buckets with 1 entries
377 buckets with 0 entries

gets : 12914318, 4814238 hits (37.28%)
sets : 8019703 (99.01% of misses)
failures: 0
used : 778 MB (94.69%) of 822 MB data cache / 958 MB total cache memory
2229936 entries (99.66%) of 2237592 total
59173 buckets with 7 entries
65009 buckets with 6 entries
58773 buckets with 5 entries
48692 buckets with 4 entries
37862 buckets with 3 entries
27838 buckets with 2 entries
21926 buckets with 1 entries
383 buckets with 0 entries

-- 
Philip