These can be done in gitHub actions CI/CD and locally
sphere_mesh()
→ pure mesh generation cost (function)create_sphere()
→ mesh generation + Bevy asset insertion + ECS entity creation (functionality)CPU performance suite
1. Function-level benchmarks
→ sphere_mesh(), tessellate_path(),
arc_path(), build_polygon_path(), compile_shader()
2. Functionality-level benchmarks
→ create_sphere(), flush_draw_commands() with many commands,
create_from_geometry(), set_property()
3. Workload tiers
→ light / medium / heavy inputs
4. Metrics
→ p50, p90, p95, p99, throughput, allocations if possible
5. CI gates
→ compare against baseline, fail only on sustained regression,
not tiny noise
(WHICH IS DONE BY BEVY)
Notes: External libraries also degrade sometimes in performance. We also need to have that in account.
processing_renderTL;DR: processing_render is mostly CPU-heavy in the parts that generate and prepare render data: tessellation, mesh generation, geometry mutation, shader/material setup, command flushing, and buffer/image conversion. These CPU-side generators are the most likely areas contributors will modify, so V1 should focus on deterministic CPU benchmarks for those hot paths.
For GPU benchmarking, we should measure the complete rendering pipeline rather than isolated snippets, because actual GPU work is mostly executed inside Bevy/wgpu. A full render benchmark harness can be added in V2 for frame time, GPU compute dispatch, readback, particles, and end-to-end scene rendering.
processing_render/src/renderprocessing_render/src/geometryprocessing_render/src/materialprocessing_render/src/particlesprocessing_render/src/transform.rsprocessing_render/src/time.rsprocessing_render/src/surface.rsprocessing_render/src/sketch.rsprocessing_render/src/shader_value.rs