Removing Iteration Setup from Benchmarks

[Anipik]

Specifying IterationSetup benchmark causes the benchmark to run just only once in an iteration. This is a problem if the benchmarks takes less than 100ms to execute.

As it is being executed just once per iteration and number of iterations is 20, no jitting is done on netcore3.0 (requires 30 calls).

The possible solutions were to increase the length + increase the warmCount to 30 (this could be a problem for other benchmarks)

Another solution is just removing the iterationSetup. In CacheWithSeeker we are not doing anything that is specific to an iteration and we can directly move the code to globalSetup.

for CacheWithCursor I moved the implementation to the actual benchmark as the iteration setup itseld was taking a small time. But it will good if we could move the iteration setup to globalSetup. @TomFinley any suggetions will be helpful.

Also Earlier this was reported as regression for netcore3.0 but after testing the benchmark with both the solutions, I found there is no regression in this benchmark.

[adamsitnik]

LGTM!

[TomFinley]

Very interesting. Thank you for such a complete explanation of the mechanics @Anipik, they were quite enlightening and will I'm sure help me write better benchmarks in future. (The JIT behavior in particular was very interesting reading!)

Regarding your specific question, cache we might prefer in setup to do an initial "pass" to ensure that the data is cached. (It caches on first access, then subsequent accesses will be cached.) But, that would all depend on exactly what the original author intended to test with this benchmark, which is not immediately clear to me. (By which I mean, maybe they were trying to capture the time it took to initially cache? But this we might suppose to be just the time of the original source data view? Who knows.)

[Anipik]

Thanks for the info @TomFinley