that data is also slow to render — let's say 200 ms per frame.
In this case, the data will be extremely slow to load — but faster if you switch to a different recording that isn't so slow to draw. The culprit, I would guess, is this logic in re_viewer’s message receiving loop:
This means that after each 10 ms portion of the data is loaded, the viewer will redraw all the (visible) data loaded so far — which means in my example of 200 ms drawing time, means it's spending 95% of its time redrawing partially-loaded data instead of getting more data loaded, and over the entire process adds up to a total load time that could be as bad as O(N²) (in the worst case where the redraw cost is proportional to the data loaded so far). In the actual scenario that inspired this report, my user experience is like: run application for 2 seconds, exit application, wait 1 minute for the viewer to finish thinking about the data it got.
Possible solutions:
Keep the 10 ms interruptions but don’t repaint until a longer period has passed; this would require being able to receive_messages() without doing it inside update().
Less refactoring, less good: adjust the 10 ms limit upward whenever drawing is especially slow, which will reduce responsiveness but perhaps still be better on net.
Ultimate engineering-heavy solution: concurrent EntityDb that allows the data source to be appending while the renderer is reading.
(Obviously, it would be better if the data wasn’t taking 200 ms to draw in this scenario. But, no matter how efficient the renderer gets, users will always have reasons to push the limits of what is feasible on the hardware they have, so I think it’s worth doing something here.)
teh-cmc
commented
1 month ago
Problem: Suppose that
In this case, the data will be extremely slow to load — but faster if you switch to a different recording that isn't so slow to draw. The culprit, I would guess, is this logic in
re_viewer’s message receiving loop:https://github.com/rerun-io/rerun/blob/06cfa9eb1c8facb435bf7de6991aa0513781e8a6/crates/viewer/re_viewer/src/app.rs#L1192-L1195
This means that after each 10 ms portion of the data is loaded, the viewer will redraw all the (visible) data loaded so far — which means in my example of 200 ms drawing time, means it's spending 95% of its time redrawing partially-loaded data instead of getting more data loaded, and over the entire process adds up to a total load time that could be as bad as O(N²) (in the worst case where the redraw cost is proportional to the data loaded so far). In the actual scenario that inspired this report, my user experience is like: run application for 2 seconds, exit application, wait 1 minute for the viewer to finish thinking about the data it got.
Possible solutions:
receive_messages()without doing it insideupdate().EntityDbthat allows the data source to be appending while the renderer is reading.(Obviously, it would be better if the data wasn’t taking 200 ms to draw in this scenario. But, no matter how efficient the renderer gets, users will always have reasons to push the limits of what is feasible on the hardware they have, so I think it’s worth doing something here.)