Address issue with setting up the partial cache in benchmark

[seddonym]

Prior to this, we would set up the state for the first iteration, but future iterations would be able to use the fully-populated cache.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #200 will degrade performances by 65.02%

_{Comparing fix-cache-benchmarking-issues (3bfddd4) with master (23da102)}

Summary

❌ 2 regressions
✅ 19 untouched benchmarks
🆕 1 new benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	test_build_django_from_cache_a_few_misses[15]	131.7 ms	376.4 ms	-65.02%
❌	test_build_django_from_cache_a_few_misses[2]	130.6 ms	165.2 ms	-20.97%
🆕	test_build_django_from_cache_a_few_misses[350]	N/A	5.8 s	N/A

[Peter554]

A bit awkward, but seems a good idea.

I'm a bit confused that the benchmark seems to take the same time as fully from the cache - I would have expected it to be a bit slower. I suppose 2 and 15 are not very big numbers, maybe it makes sense to add a case where we are missing 100, or 1000 cache entries.

[codspeed-hq]

CodSpeed Walltime Performance Report

Merging #200 will not alter performance

_{Comparing fix-cache-benchmarking-issues (b5a86ae) with master (f6cabfe)}

Summary

✅ 21 untouched benchmarks

[seddonym]

I'm a bit confused that the benchmark seems to take the same time as fully from the cache - I would have expected it to be a bit slower. I suppose 2 and 15 are not very big numbers, maybe it makes sense to add a case where we are missing 100, or 1000 cache entries.

I've added one for 350 misses (about half of Django). It does slow the benchmarking job down quite a bit unfortunately, maybe we can remove it later.

I've also adjusted it so it copies a real module from Django instead of a one-liner, so the parser will have more work to do.