El adaptador era el cuello de botella, no el SLAM
gemm1 min de lectura
Pasamos semanas optimizando un pipeline de SLAM cuyo límite real era la capa que traducía entre dos formatos de mensaje. La lección es sobre a dónde apuntás un profiler, no sobre SLAM.
Nuestro mapa en vivo llegaba tarde y estábamos seguros de que la causa era el SLAM. FAST-LIVO2 hace trabajo real en cada frame — obviamente era la parte cara.
No lo era. La parte cara era el adaptador: una capa de apariencia fina entre el formato de mensaje del nodo de SLAM y el que esperaba el transporte. Copiaba, reallocaba, y lo hacía por frame.
Qué me llevo de esto
"Obviamente caro" es una hipótesis, no una medición. La parte sospechosa de un sistema rara vez es la que corre el algoritmo famoso; casi siempre es el pegamento aburrido sobre el que nadie escribió un paper, porque nadie lo mira.
Y el corolario que nos costó más tiempo: también habíamos encontrado que el path de SLAM estaba saturando el link de WiFi, y arreglarlo produjo una mejora real. Lo que nos dio más confianza en el modelo equivocado, no menos. Dos problemas en la misma zona, uno de ellos real, es la peor forma posible para debuggear.