Large performance regression (compared to 0.21) for missing query cache

[Wumpf]

This test scene alien_cake_addict.rrd.zip plays (!) now a lot slower.

On my Mac Rerun reports 90ms on 0.21 and 270ms cpu time on 92949cf.
When paused it it went from 50ms to 65ms (also bad, but not as crazy).

From a first glimpse it seems that the cost of not hitting the query cache has gone up considerably, but more investigation is needed.
This may be temporary due to the ongoing arrow/arrow2 conversion. (shipblocking in any case!).

[emilk]

Since this is a scene with a huge number of objects, I suspect the added overhead of arrow1<->arrow2 conversions is to blame. The conversions are always zero-copy, but usually still involve a few small allocations and pointer-chasing, so they are by no means free.

[emilk]

fn row_sliced is being called almost 9k times per frame, and is around 10µs slower than it was before (per call). I'm investigating why.

row_ids and time columns have both been switched to arrow1, but initial investigation indicates this is not what is slower. It could maybe be related to tagging (ComponentDescriptor)?

[emilk]

This is super-weird. It is this piece of code that has become slower:

https://github.com/rerun-io/rerun/blob/0.21.0/crates/store/re_chunk/src/slice.rs#L110-L118

The things is - the code hasn’t changed:

https://github.com/rerun-io/rerun/blob/main/crates/store/re_chunk/src/slice.rs#L109-L117

Nor has the types surrounding it. Maybe the new Rustc optimizes worse? I think I need to git bisect 😭

[emilk]

This is the PR that regressed performance:

• Port PendingRow to arrow-rs #8617

But why?

Specifically this commit:

• 78f676f

I wonder if the arrow2 -> arrow -> arrow2 conversions adds a null-array or something… 🤔