Slow rendering causes data ingestion to be even slower

[kpreid]

Problem: Suppose that

• you have a large amount of data to load, and
• 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:

rerun/crates/viewer/re_viewer/src/app.rs

Lines 1192 to 1195 in 06cfa9e

	if start.elapsed() > web_time::Duration::from_millis(10) {
	egui_ctx.request_repaint(); // make sure we keep receiving messages asap
	break; // don't block the main thread for too long
	}

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]

See:

• Consider a mode where the UI is "off" during ingestion, in order to limit the UI-specific overhead #5812
• Data ingestion starved when in background #1960

which lead to:

• Parallelize data ingestion #4298

which requires:

• Introduce cheaply clonable ChunkStoreHandle and QueryCacheHandle #7486