teh-cmc
commented
1 day ago What does performance look like when we only do the querying + chunk processing part? I.e. let's pretend we've managed to optimized out everything that visualizers do after receiving the chunks (range-zipping, color/radii/etc splatting, annotation context...).
We need to know this because our upcoming aggregated caching plan still involves running the queries every frame.
I've applied the following patch, which (very broadly) simulates that:
Click for diff
```diff diff --git a/crates/viewer/re_space_view/src/results_ext.rs b/crates/viewer/re_space_view/src/results_ext.rs index 55e52be3e00..01d5cae4e17 100644 --- a/crates/viewer/re_space_view/src/results_ext.rs +++ b/crates/viewer/re_space_view/src/results_ext.rs @@ -427,7 +427,7 @@ impl<'a> HybridResultsChunkIter<'a> { pub fn componentFirst, let's look at unmodified main (on my machine with discrete GPU, i.e. hard mode):
main, latest-at, without plot:
main, latest-at, with plot:
main, infinite range for 3D view / latest-at for the rest, without plot:
main, infinite range for 3D view / latest-at for the rest, with plot:
Now here's where it gets interesting: consider what happens
main, latest-at, without plot -- Chunk processing only:
(NOTE: The specific values is the flamegraph are inflated due to probing overhead).
main, infinite range for 3D view / latest-at for the rest, without plot -- Chunk processing only:
It looks like we can definitely afford to run the queries every frame, as long as we manage to make aggregated caching work.
Context
We want the viewer to be able to scale to scenes with large numbers of entities. This of course means visualizing these scenes, but also ingesting them in the first place.
This is blocked on a number of specific implementation issues, but put broadly: the work the viewer has to do to layout a scene more often than not grows linearly with the number of entities present in the entire dataset.
There are only two ways to combat this:
Of course in many cases, option 1 isn't even an option: if the user wants to visualize all entities in the scene, then somehow we have to make that fast.
Incremental caching of aggregated data (which is what the visualizers work with) is very hard, but will be a must in order to reach our performance goals.
This issue is not about:
Measurable end goals
Air Traffic example (
2hdataset)TODO(cmc): What should we do about plotting? Is plotting 10k lines on a single plot really an important use case? If so, do we need to bring egui issues into this?
Revy
Revy was infamously bottlenecked by the performance of many entities (game scenes have a lot of them). This is a good opportunity to revive that project, if we can make it happen.
Relevant material
Writings:
PRs:
Sub-issues
To be replaced with actual sub-issues once/if we have access to them. We can also remove the
project-many-entities-perflabel at that point.Areas that need significant improvements
query_results)spawn_heuristic_space_views)Wherever we don't do something obviously silly, we should strive to go with a retained/cached approach in order to get more scalable and robust against the per-frame regressions in trivially looking (== static frame) scenarios If this is structurally hard, revisit structure!