Philip Martin <phi...@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
