Think about tuning the script cache/sigcache ratios

[TheBlueMatt]

After #10192, we have two separate caches, which are in memory blocks of equal size. This is likely not the best possible tuning, but sadly its tricky to get right because the sigcache is now used more as a DoS protection/reorg speedup and less as a cache used in normal operation. See-also, @JeremyRubin's suggestion of using the same table and further discussion at, eg, https://github.com/bitcoin/bitcoin/pull/10192#issuecomment-313334895.

[gmaxwell]

I am astonished that as many random memory access as we're making for these things is actually well tuned. I'd really like to understand how 8 way fanout is optimal, if it is, since that amount of memory latency should significantly slower than e.g. four way fanout into buckets of two esp with caches much larger than L3. Reports were that it wasn't which suggests to me that something is wrong, either in our implementation or in my understanding of the hardware, maybe our hash function is too slow and thats obscuring it.

Another thing to look at is tuning the eviction/epoch counter part.

[JeremyRubin]

Greg I think your understanding is deficient, the actual expected number of probes should be a lot closer to 1 for signatures that exist. This is because a recently inserted transaction should be close to it's first hash-index and a recently inserted transaction is more likely to be mined.

If you want to simulate the worst case you should write a benchmark that tests the cache with a block that has all previously unseen signatures/transactions.