re_datastore: puffin probes!

[teh-cmc]

This is pretty much the only thing left before we can close #443 (despite the issue telling otherwise 😬).

[emilk]

Nice with scopes!

What does the puffin flamegraph of nyud look like now?

In the other crates we only include puffin on native, because it adds quite a bit of wasm for very little gain (timers only have 1ms accuracy on web).

So all other crates do this:

/// Profiling macro for puffin
#[doc(hidden)]
#[macro_export]
macro_rules! profile_function {
    ($($arg: tt)*) => {
        #[cfg(not(target_arch = "wasm32"))]
        puffin::profile_function!($($arg)*);
    };
}

/// Profiling macro for puffin
#[doc(hidden)]
#[macro_export]
macro_rules! profile_scope {
    ($($arg: tt)*) => {
        #[cfg(not(target_arch = "wasm32"))]
        puffin::profile_scope!($($arg)*);
    };
}

and then use crate::profile_function etc.

[teh-cmc]

nyud (release, no history):

nyud (release, 0.6s history for point cloud (any more than that crashes!!)):

I'll open an issue for the weird behaviors I'm seeing with the history.

[emilk]

I think might have gotten a bit overboard with the number of profiling scopes. This is the "plot" demo:

Each puffin call has an overhead of around 100ns-200ns, so that's a per-frame overhead here of ~3-6ms, which is too much. We should try to keep the number of total profile scopes below 10k.

…or, perhaps SceneTimeSeries::load_Scalars is calling ::get way too often, and we should fix that. I'm not looking any deeper right now (I'm busy with other stuff!)

There is also some levels in the profiling missing - I don't immediately understand what part of SceneTimeSeries::load_scalars is actually calling the underlying get methods.

(NOTE: this overhead is only when a profiler is actually connected. When profiling is off, the per-call overhead drops from ~100ns to ~1ns)

EDIT:

• Tweak store profile scopes #979