Qué intentaba resolver la prueba
La idea era construir una función personalizada de SQLite capaz de convertir cadenas como `-$1,234.56` o `12.5%` en valores numéricos que luego pudieran sumarse y ordenarse. La implementación debía eliminar separadores y símbolos monetarios, interpretar un signo menos inicial y devolver `NULL` cuando el texto no pudiera analizarse. Para arrancar el experimento, el autor se apoyó en Claude Opus 5.5 como punto de partida.
A partir de ahí comparó dos vías: escribir la extensión en C o hacerlo en Rust. El primer resultado ya dejaba una diferencia importante de tamaño: la extensión en Rust medía 321 KB con rusqlite y 298 KB con sqlite-loadable-rs, mientras que la de C se quedaba en 14 KB.
La sorpresa inicial: Rust iba por delante
En la primera ronda de pruebas, la versión en Rust salió mejor parada que la primera implementación en C. La explicación estaba en una pieza muy concreta del proceso: el equivalente en Rust de `strtod ` resultaba aproximadamente dos veces más rápido, así que el cuello de botella no era el lenguaje en sí, sino la rutina usada para convertir texto en número.
Ese hallazgo cambió el enfoque. En vez de dar por buena la primera versión en C, el autor pidió rehacer la función decimal para que pudiera alcanzar o superar el rendimiento de Rust. El cambio no fue menor: afectó al núcleo del parseo y redujo de forma clara el coste por fila.
El C afinado acaba imponiéndose
En la versión mejorada, la comparación sobre 2 millones de filas dejó estos resultados: en datos mixtos, el primer C se movía en 67 ns por fila, el C nuevo bajó a 19 ns, rusqlite quedó en 46 ns y sqlite-loadable en 41 ns. En enteros puros, el nuevo C marcó 16 ns frente a 25 ns del primer C, 36 ns de rusqlite y 32 ns de sqlite-loadable. En decimales, la mejora fue todavía más clara: 18 ns frente a 106 ns de la versión inicial en C, 55 ns de rusqlite y 47 ns de sqlite-loadable.
El resultado práctico es claro: cuando la lógica es muy concreta y la ruta de ejecución está bien afinada, C puede competir muy bien, incluso frente a implementaciones en Rust. La comparación no demuestra que un lenguaje sea “mejor” que otro en abstracto; demuestra que la implementación concreta pesa más de lo que suele parecer al principio.
Qué deja esta comparación para desarrollo
La pieza aporta dos lecciones útiles. La primera es que el coste de una extensión no se mide solo por la facilidad de escribirla, sino también por el tamaño del artefacto final y por el comportamiento por fila cuando el código se ejecuta miles o millones de veces. La segunda es que Rust no garantiza automáticamente mejor rendimiento, igual que C no garantiza por sí solo un binario pequeño si el código no está bien afinado.
También hay un detalle metodológico relevante: el autor acompañó la comparación con pruebas de corrección, preservación de tipos, reglas de análisis y 8 millones de comprobaciones de fuzzing. Eso no convierte el experimento en un estándar industrial, pero sí refuerza la idea de que las versiones comparadas hacían realmente lo mismo.
Para equipos que trabajan con SQLite embebido, extensiones de análisis o utilidades que deben desplegarse con poco margen de tamaño, la diferencia entre 14 KB y varios cientos de kilobytes no es trivial. Tampoco lo es pasar de decenas de nanosegundos por fila a cifras mucho más altas cuando el análisis se repite sobre millones de registros.
Queda por ver cómo se comportaría esta misma idea en una extensión más compleja, con más validaciones o formatos admitidos, porque ahí es donde cambiarían de verdad las prioridades entre tamaño, legibilidad y velocidad.
