Correctly restore unstable encoding corpus and create tokio runtime only once per process#8480
Conversation
…nly once per process Signed-off-by: Robert Kruszewski <github@robertk.io>
Merging this PR will degrade performance by 22.94%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | slice_empty_vortex |
368.3 ns | 2,657.8 ns | -86.14% |
| ❌ | Simulation | chunked_bool_canonical_into[(1000, 10)] |
20.3 µs | 35.7 µs | -43.24% |
| ❌ | Simulation | slice_vortex_buffer[1024] |
871.4 ns | 1,305.8 ns | -33.27% |
| ❌ | Simulation | slice_vortex_buffer[16384] |
871.4 ns | 1,305.8 ns | -33.27% |
| ❌ | Simulation | slice_vortex_buffer[2048] |
871.4 ns | 1,305.8 ns | -33.27% |
| ❌ | Simulation | slice_vortex_buffer[128] |
871.4 ns | 1,305.8 ns | -33.27% |
| ❌ | Simulation | slice_vortex_buffer[65536] |
871.4 ns | 1,305.8 ns | -33.27% |
| ❌ | Simulation | chunked_varbinview_canonical_into[(1000, 10)] |
162.2 µs | 198.1 µs | -18.09% |
| ❌ | Simulation | chunked_varbinview_into_canonical[(1000, 10)] |
177.7 µs | 214 µs | -16.98% |
| ❌ | Simulation | search_index_below_min_chunked |
1.3 ms | 1.5 ms | -13.61% |
| ❌ | Simulation | search_index_mixed_out_of_range_chunked |
1.3 ms | 1.5 ms | -13.3% |
| ❌ | Simulation | count_i32_clustered_nulls |
47 µs | 53.9 µs | -12.78% |
| ❌ | Simulation | search_index_full_range_random_chunked |
1.4 ms | 1.6 ms | -12.06% |
| ❌ | Simulation | chunked_varbinview_canonical_into[(100, 100)] |
273.2 µs | 308.8 µs | -11.53% |
| ⚡ | Simulation | take_10k_random |
255.8 µs | 197.7 µs | +29.39% |
| ⚡ | Simulation | take_10k_contiguous |
276.3 µs | 218.1 µs | +26.66% |
| ⚡ | Simulation | patched_take_10k_contiguous_patches |
291 µs | 232.1 µs | +25.39% |
| ⚡ | Simulation | patched_take_10k_random |
303 µs | 244 µs | +24.18% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing rk/fuzzercleanup (e98480c) with develop (69ce1ed)2
Footnotes
-
50 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
-
No successful run was found on
develop(cb82828) during the generation of this report, so 69ce1ed was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
I'm trying to get fuzzer into happier state, these two things showed up as obviously wrong