This adds benchmarks to track build time and build memory use
with dev and scu builds.
Dev and scu builds are what (regular) contributors will be running
most often, so it makes sense to benchmark them for targeted optimization.
`--quit-after` is not reliable in this scenario, requiring a value
as high as 12 to reliably import resources without crashing.
`--import` handles this in a more robust manner.
- Use 1200px as website width, and make it a 3-column layout.
- Switch graphs to log y scale, and show 0.2x to 5x by default.
ApexCharts currently struggles with log y scales, glitches with outliers
(at least in Safari), and does not support extensive graph interaction
(like double clicking traces to isolate, and the toolbar).
- Always use relative values to display benchmarks
(actual values are platform dependent and meaningless).
- Use the median of the last 10 values as middle, such that new benchmarks
are always on the graph.
- Don't round values in the data aggregator, round them on visualization
instead.
- Use toolbar in detail charts.
- Don't use shared tooltip.
Previously, ticks on the x-axis are currently positioned perfectly sequentially.
This can skew results when timing between samples is inconsistent.
This graphing bug partially explained some jumps in the current graphs.
---------
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
These benchmarks represent stress tests that challenge the CPU
with lots of animation calls.
This also adds a default environment that makes it easier to distinguish
objects from the background, even when there is no light in the scene.
`compile_commands.json` is required for many IDEs and can be generated using
`scons compiledb=yes compile_commands.json`.
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
The user can click "Show all benchmarks..." at the end to reveal
the full list of benchmarks.
Benchmarks are also now ordered from newest to oldest, instead
of from oldest to newest.
This ensures release builds use the same behavior as debug builds here.
The benchmarks project does not spam print messages anyway, so performance
should be identical to before.
