pbf VS flatbush

it's been about 3 years, but in Grafana at the time we were using something like ArrowJS + Arrow Flight + protobuf.js and then render the datasets into dashboards on Canvas, especially for streaming at ~20hz.

when i benchmarked the fastest lib to simply convert the protobuf decode (https://github.com/mapbox/pbf), it was 5x slower than native JSON parsing in browsers for dataframe-like structures (e.g. a few dozen 2k-long arrays of floats).

does it beat https://github.com/mapbox/pbf ?

at least in the frontend (without WASM), it depends.

i tested https://github.com/mapbox/pbf and while it was faster for deep/complex structs vs an unoptimized/repetative JSON blob, it was slower at shallow structs and flat arrays of stuff. if you spend a bit of time encode stuff as flat arrays to avoid mem alloc, JSON parsing wins by a lot since it goes through highly optimized C or assembly, while decoding protobuf in the JIT does not.

The runtime is taken from mapbox/pbf (with basic type definitions)

> (There are ECS frameworks in JavaScript, which gives you absolutely no control over memory layout and thus completely defeats one of the primary purposes of the pattern.)

While JS does not provide great support for bit packing complex structs, typed arrays give you quite a bit of control over memory layout for simple numeric types, which is what you usually want for optimal data-oriented code anyway. This is a common technique used in fast JS libs for data visualization, ie:

https://github.com/mourner/flatbush

There are also basic operators required for bitarrays, which are useful for ECS and memory-efficient code generally.

using flatbush library instead of rbush which optimise the statically placed element, from the benchmark in the repository it could boost up to 5x the performance of rbush.

But for 500 k points, it's not many. I'd put it in the database tech I was using and hit an API for it. Or like you say, load it into memory and use Mourner's flatbush for a super simple and super fast solution..

> At pbf speeds, decoding is usually no longer a bottleneck, but bandwidth might be when comparing with gzipped JSON.

we were streaming a few hundred datapoints in a dozen flat arrays over websocket at 20-40hz and needed to decode the payload eagerly. plain JSON was a multi-factor speedup over pbf for this case. but it's fully possible i was holding it wrong, too!

even if your "bottleneck" is rendering/rasterization (10ms), but your data pipe takes 5ms instead of 1ms, it's a real effect on framerate, battery, thermals, etc.

i'm a big fan of your work! while i have you here, would you mind reviewing this sometime soon? ;)

https://github.com/mourner/flatbush/pull/44