# The adapter was the bottleneck, not the SLAM

- Date: 8 September 2026
- Project: gemm
- Tags: Robotics, Debugging, SLAM

> 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.

---

Page: https://eitanf.com/notes/the-adapter-was-the-bottleneck · Español: https://eitanf.com/es/notes/the-adapter-was-the-bottleneck.md · llms.txt: https://eitanf.com/llms.txt