The adapter was the bottleneck, not the SLAM
gemm1 min read
We spent weeks optimising a SLAM pipeline whose real limit was the layer translating between two message formats. The lesson is about where you point a profiler, not about SLAM.
Our live map was arriving late and we were certain the cause was the SLAM itself. FAST-LIVO2 is doing real work on every frame — of course it was the expensive part.
It was not. The expensive part was the adapter: a thin-looking layer between the SLAM node's message format and the one the transport expected. It copied, it reallocated, and it did that per frame.
What I would take from this. "Obviously expensive" is a hypothesis, not a measurement. The suspicious part of a system is rarely the part doing the famous algorithm; it is usually the boring glue nobody wrote a paper about, because nobody looks at it.
The corollary that cost us more time: we had also found that the SLAM path was saturating the WiFi link, and fixing that produced a real improvement. Which made us more confident in the wrong model, not less. Two problems in the same area, one of them real, is the worst possible shape for debugging.