ast.walk puede ser 220x más rápido

Si trabajas con linters, IDEs o cualquier herramienta que inspeccione código Python, hay una parte del pipeline que se repite una y otra vez: recorrer el AST. Ese recorrido parece barato hasta que lo haces miles de veces por archivo, en cientos de archivos, dentro de un editor que se actualiza mientras escribes o en un CI que corre reglas de calidad sobre un monorepo.

La noticia interesante no es solo que alguien logró hacer ast.walk hasta 220 veces más rápido. Lo relevante es lo que eso desbloquea: menos latencia en el editor, menos tiempo de espera en análisis estático, menos CPU desperdiciada en pipelines y, sobre todo, más margen para agregar reglas sin que todo se vuelva lento.

Qué problema resuelve ast.walk

En Python, el AST, o Abstract Syntax Tree, es la estructura que representa el código después de parsearlo. Herramientas como linters, formateadores, analizadores de seguridad, refactorizadores e incluso algunos features de IDE usan ese árbol para entender qué hace tu código sin ejecutarlo. La función ast.walk recorre todos los nodos del árbol de forma sencilla, pero esa sencillez tiene un costo.

El problema aparece cuando no haces un solo recorrido. Un linter puede hacer varios pases sobre el mismo archivo: buscar imports, detectar variables no usadas, encontrar funciones demasiado complejas, revisar patrones de seguridad y más. Si cada regla vuelve a caminar el AST por su cuenta, el costo se multiplica. En un archivo pequeño no pasa nada. En un proyecto grande, la diferencia entre 1x y 220x deja de ser un detalle técnico y se convierte en tiempo real para quien programa.

Por qué un recorrido simple puede ser caro

ast.walk está pensado para ser generalista. Eso lo hace cómodo, pero no necesariamente óptimo para casos donde ya conoces el patrón de acceso. Por ejemplo, si solo te interesan ciertos tipos de nodos, recorrer todo el árbol y filtrar después implica trabajo extra. Si además repites el proceso en cada regla, el costo se duplica o triplica sin que el usuario vea ningún valor adicional.

En tooling de desarrollo, la latencia visible importa más que el throughput bruto. Un editor que tarda 50 ms en mostrar un diagnóstico se siente fluido. Uno que tarda 500 ms ya interrumpe el flujo. En CI, esa diferencia se acumula por cada archivo y por cada regla. Por eso una optimización sobre AST no es un micro-optimización aislada: impacta la experiencia de uso de toda la cadena.

El contexto técnico de la mejora

La idea detrás de una aceleración así suele ser simple de explicar y difícil de implementar bien: reducir trabajo repetido, mejorar el acceso a nodos relevantes y aprovechar mejor la estructura del árbol. En el caso que motivó este artículo, el foco fue hacer el recorrido más eficiente para un uso muy concreto dentro de tooling en Python. La documentación de Python sobre el módulo ast explica la estructura base y la API disponible, y sirve como referencia para entender qué se está recorriendo exactamente: https://docs.python.org/3/library/ast.html

No hace falta que memorices cada nodo del AST para ver el impacto. Basta con entender que, si una herramienta analiza el código en cada guardado, cada cambio y cada ejecución de CI, cualquier reducción del tiempo por archivo se multiplica rápido.

Cómo se logra una mejora de 220x

Una mejora de 220x no suele venir de un truco mágico. Normalmente aparece cuando combinas varias decisiones: menos asignaciones de objetos, menos iteraciones, mejor selección de nodos, y una estrategia más cercana al caso de uso real. En otras palabras, no se trata de “hacer Python más rápido” en abstracto, sino de dejar de pagar por trabajo que no necesitas.

En análisis estático, el patrón clásico es este: parseas el archivo, recorres el AST, aplicas reglas y generas resultados. Si una optimización permite que el recorrido sea muchísimo más barato, todo lo que depende de ese paso baja de costo. Y eso cambia la ecuación de diseño de la herramienta: puedes correr más checks, más seguido, con menos fricción para el usuario.

Menos pasos, más intención

La mejora de rendimiento suele venir de acercar el código a la intención real del análisis. Por ejemplo, si una regla solo necesita funciones y clases, no tiene sentido tratar cada nodo hoja con el mismo nivel de atención. Si puedes indexar o filtrar mejor, el recorrido deja de ser un barrido completo y se parece más a una consulta dirigida.

Ese cambio tiene efectos prácticos. Una regla que antes era demasiado cara para correr en tiempo real dentro del editor puede pasar a ser viable. Otra que se ejecutaba solo en CI puede moverse a pre-commit. Y una tercera, que se había descartado por costo, puede volver al backlog del equipo porque ya no rompe el presupuesto de latencia.

Un ejemplo de impacto medible

Supón que una herramienta analiza 1,000 archivos y cada archivo requiere 20 recorridos del AST. Si cada recorrido tarda 2 ms, solo ese tramo consume 40 segundos. Si logras una mejora de 220x en una parte crítica del proceso, el tiempo total no baja 220x completo, porque hay otros costos alrededor, pero sí puede caer lo suficiente como para cambiar una ejecución de minutos a segundos.

La tabla no pretende prometer una cifra universal. El punto es otro: cuando el recorrido deja de ser el cuello de botella, el resto del sistema se vuelve más visible. A veces descubres que el problema real ya no era el AST, sino la lectura de disco, la serialización de resultados o la red en un servicio remoto.

Qué cambia para linters, IDEs y tooling

Si tú mantienes o usas herramientas como Ruff, Pyright, plugins de VS Code o analizadores internos, una mejora de este tipo no es solo una nota técnica. Es una oportunidad para cambiar la frecuencia con la que ejecutas reglas y el lugar donde las ejecutas. Lo que antes era demasiado costoso para correr en cada tecla puede pasar a correr en segundo plano sin molestar.

También cambia la forma en que diseñas reglas. Cuando el costo del recorrido baja, se vuelve más razonable agregar validaciones que antes eran demasiado caras. Eso ayuda a equipos que quieren más seguridad o más consistencia sin pagar con lentitud en el editor.

En el editor: menos espera, más feedback útil

En un IDE, el usuario espera respuestas casi inmediatas. Si una regla de análisis tarda demasiado, el editor termina mostrando diagnósticos tarde o agrupados, y eso reduce su valor. Una mejora fuerte en AST puede reducir la sensación de “el editor piensa demasiado”.

Piensa en un caso real: escribes una función, guardas, y el linter te marca un import no usado. Si eso aparece al instante, corriges y sigues. Si aparece varios segundos después, ya cambiaste de contexto. El costo no es solo técnico, también es cognitivo.

En CI y pre-commit: más checks sin castigar al equipo

En pipelines de código, el beneficio es distinto. Ahí no importa tanto la latencia de una sola acción, sino el tiempo total que tarda el flujo. Si un análisis estático se ejecuta sobre cientos de archivos en cada PR, una mejora en el recorrido del AST puede ahorrar minutos por ejecución. Eso reduce colas, acelera merges y baja la tentación de desactivar checks por lentitud.

Una forma práctica de pensar esto es por capas:

1. Parseo del código.
2. Recorrido del AST.
3. Evaluación de reglas.
4. Formateo o reporte de resultados.
5. Integración con editor, CLI o CI.

Si aceleras la capa 2, puedes rediseñar el balance de las otras. Por ejemplo, puedes permitir más reglas en el editor y dejar solo las más pesadas para CI. O puedes correr análisis más frecuentes sin penalizar tanto el tiempo total del pipeline.

Qué significa para equipos en LatAm

En LatAm, el tema de performance tiene una dimensión muy concreta: hardware heterogéneo, conexiones variables y equipos que suelen trabajar con varios servicios abiertos al mismo tiempo. Una herramienta que consume menos CPU y responde más rápido no solo mejora la experiencia del desarrollador senior en una MacBook potente. También ayuda a quien usa una laptop de gama media o una máquina compartida en una oficina.

Además, muchas empresas de la región trabajan con equipos distribuidos y repositorios grandes. En ese contexto, cada segundo ahorrado en validación local o en CI se siente más. Si tu equipo hace decenas de PRs al día, una reducción pequeña por archivo puede sumar horas al mes.

Coste de oportunidad real

Cuando una herramienta es lenta, el equipo suele compensar de tres maneras: desactiva reglas, reduce frecuencia de análisis o tolera más ruido. Ninguna de esas opciones es ideal. Si el análisis se vuelve barato, puedes mantener más cobertura sin castigar la productividad.

Eso también impacta la adopción. En muchos equipos, las herramientas internas fracasan no porque detecten mal, sino porque tardan demasiado. Un análisis rápido se usa más. Y cuando se usa más, aporta más valor. Esa relación entre latencia y adopción es fácil de subestimar.

Qué deberías mirar si tu equipo mantiene tooling propio

Si tú estás construyendo herramientas de calidad de código, vale la pena revisar estas preguntas:

• ¿Cuántas veces recorres el AST por archivo?
• ¿Tus reglas comparten información o repiten trabajo?
• ¿Estás analizando todo el árbol cuando solo te interesan ciertos nodos?
• ¿El tiempo va al parseo, al recorrido o al reporte?
• ¿Tu tooling corre en editor, CLI, CI o en los tres?

La respuesta a esas preguntas te dice dónde está el costo real. Muchas veces el problema no es el parser, sino la estrategia de recorrido. Y ahí es donde una mejora grande como esta puede cambiar el diseño del sistema.

Cómo pensar una optimización así en tu propio código

No necesitas esperar a una biblioteca externa para aplicar la misma lógica. Si tu proyecto hace análisis estructural sobre código, JSON, YAML o cualquier árbol de datos, el principio es el mismo: no recorras más de lo necesario, no repitas trabajo y mide antes de tocar nada.

La documentación oficial de Python sobre timeit y profiling puede ayudarte a medir mejor antes de optimizar: https://docs.python.org/3/library/timeit.html y https://docs.python.org/3/library/profile.html

Un enfoque práctico en 5 pasos

1. Mide el tiempo real de tus reglas con archivos representativos, no con ejemplos mínimos.
2. Identifica si el costo está en parseo, recorrido, filtrado o serialización.
3. Agrupa reglas que usan la misma información para evitar múltiples pasadas.
4. Reduce el conjunto de nodos visitados cuando el caso de uso lo permita.
5. Repite la medición con datos reales de tu repo y no con supuestos.

Ese orden importa. Si optimizas sin medir, puedes mover el costo de un lado a otro y terminar igual o peor. Si mides bien, puedes descubrir que una mejora del recorrido del AST te permite simplificar otras partes del sistema.

Cuándo vale la pena invertir en este tipo de mejora

Vale la pena cuando el análisis se ejecuta muchas veces por día, por archivo o por usuario. También cuando el costo de latencia afecta la adopción. Si una herramienta es rápida, la gente la deja activada. Si es lenta, la desactiva y luego se pregunta por qué no detecta problemas.

También vale la pena cuando tu producto depende de feedback inmediato. Un IDE, un agente de código, un sistema de validación en tiempo real o un servicio de revisión automática se benefician más que una tarea batch que corre una vez por semana. Ahí es donde el número 220x deja de ser una curiosidad y se convierte en una ventaja de diseño.

Tabla resumen

La lectura útil de este caso no es “mira qué rápido se puede hacer ast.walk”. Es más bien: si una parte pequeña del pipeline se usa miles de veces, optimizarla cambia la vida del resto del sistema. Y eso vale para Python, para tooling interno y para cualquier producto donde la experiencia del desarrollador dependa de respuestas rápidas.

Si tú construyes herramientas de código, esta clase de mejora te recuerda algo simple: la performance no solo sirve para ahorrar segundos. Sirve para decidir qué features son viables, dónde correrlas y con qué frecuencia. Cuando el análisis deja de ser caro, el diseño del producto también cambia.