Skip to content

Commit 885d16d

Browse files
committed
Document pool_peak_bytes for benchmark authors
The README's "Collecting data" section is the contract benchmarks follow to produce results JSON, and it did not mention the new field or the `set_memory_pool` call that populates it.
1 parent 6dce8d6 commit 885d16d

1 file changed

Lines changed: 8 additions & 0 deletions

File tree

benchmarks/README.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -483,6 +483,14 @@ Your benchmark should create and use an instance of `BenchmarkRun` defined in `b
483483
- Call its `start_new_case` method with a string that will appear in the "Query" column of the
484484
compare output.
485485
- Use `write_iter` to record elapsed times for the behavior you're benchmarking.
486+
- Call `set_memory_pool` with the `RuntimeEnv`'s memory pool (`ctx.runtime_env().memory_pool`),
487+
and again for each new runtime if your benchmark builds one per query. Each case then reports a
488+
`pool_peak_bytes` field: the peak `MemoryPool` reservation reached while running it, which is the
489+
largest value across that case's iterations. The field is omitted when the benchmark runs without
490+
`--memory-limit`, since no pool is installed to record. Comparing it against the peak RSS printed
491+
by `print_memory_stats` shows how much of the run's memory the pool actually accounted for; the
492+
pool only tracks the "large" allocations that scale with input size, so the two are expected to
493+
differ.
486494
- When all cases are done, call the `BenchmarkRun`'s `maybe_write_json` method, giving it the value
487495
of the `--output` structopt field on `RunOpt`.
488496

0 commit comments

Comments
 (0)