En los últimos dos meses, el equipo del compilador Rust ha registrado un trabajo significativo, y los datos lo reflejan. Desde el 29 de julio hasta el 28 de septiembre, rastrearon 629 ejecuciones de referencia, con un tiempo promedio de ahorro de 4,57%. El informe del propio equipo describe esto como una ganancia notable en rendimiento durante ese corto período.
El documento, titulado «Cómo acelerar el compilador Rust en septiembre de 2026», sigue los numerosos componentes cambiantes del compilador, desde la herramienta que verifica el préstamo hasta el sistema que resuelve los rasgos hasta la utilidad de documentación conocida como rustdoc. El resultado se describe con el término «un mar de verde»: la mayoría de las pruebas de rendimiento mostraron ganancias, mientras que solo un pequeño número se movió en la dirección opuesta.
Rustdoc Wins
Rustdoc, la herramienta que produce las páginas de documentación de Rust, ha recibido algunas mejoras importantes en la velocidad de Noah Lev. Él ha escrito un relato exhaustivo de su enfoque, y el equipo describe la lectura como «interesante y satisfactoria», señalando que el trabajo ha hecho que la herramienta sea significativamente más rápida.
Jakub Beránek introdujo PGO, o optimización guiada por el perfil, en Clippy, y ese movimiento produjo grandes ganancias en el tiempo de pared en casi todos los puntos de referencia de Clippy. El avance más grande provino de una mejora del 18%.
La Actualización de LLVM
La versión de LLVM del compilador se actualizó a LLVM 23, cortesía de la actualización de Nikita Popov. Dichas actualizaciones suelen producir ganancias de rendimiento, y esta redujo el tiempo medio de pared en todos los puntos de referencia en un 1,2%. El informe califica ese resultado como genuinamente sorprendente para una sola solicitud de extracción.
Polonius y Penelope
El nuevo verificador de préstamos, Polonius, ha llegado a Nightly. Ofrece una mayor precisión que su predecesor, aceptando ciertos programas válidos que el verificador anterior rechazaría. También asume más trabajo, lo que en un pequeño número de casos extiende notablemente el tiempo de compilación, incluido para el ampliamente utilizado crate serde.
Jack Huey abordó el problema y convirtió los cálculos de liveness en perezosos en lugar de inmediatos, lo que redujo el número de instrucciones en un 3-5% y en algunos otros puntos de referencia en menos del 1%.
Huey realizó ajustes a una estructura de datos y llevó a cabo algunos cambios de inserción, lo que resultó en reducciones en el recuento de instrucciones inferiores al 1% en numerosos puntos de referencia.
Anoche también se activó Penelope Hammertime, el nuevo solucionador de rasgos, que funciona más lentamente en un número reducido de casos, al igual que Polonius. Jana Dönszelmann publicó un análisis exhaustivo del trabajo destinado a acelerarlo.
El documento enumera una serie de pull requests elaboradas por el autor: #160479, #160605, #160801, #160892, #161077 y #161211. Algunas de esas modificaciones redujeron significativamente el tiempo de compilación para crates específicos que eran lentos: 50% en un caso, 25% en otro y 15% en otros lugares, con una prueba de estrés viendo una reducción aún mayor.
Run de xmakro
xmakro mantuvo su racha de contribuciones sólidas con otra mejora. Esta vez optimizaron cómo se manejan los impls durante la construcción del grafo de especialización, y el resultado fue una reducción promedio en el recuento de ciclos de 1.58% en todos los benchmarks. Eso es una ganancia significativa proveniente de una sola pull request.
La carga de datos de compilación incremental se hizo más eficiente gracias al trabajo de xmakro, reduciendo el recuento de instrucciones en varios benchmarks, con la reducción más dramática alcanzando el 6%. Un cambio aparte eliminó algunas asignaciones de una ruta de procesamiento de obligaciones frecuentemente utilizada, también reduciendo el recuento de instrucciones en muchos benchmarks, con la mejora más grande alcanzando el 2%.
xmakro cambió el código de selección del solucionador de rasgos antiguo/nuevo a despacho estático en lugar de despacho dinámico. Ese cambio entregó principalmente reducciones en el recuento de instrucciones inferiores al 1% en varios benchmarks. La ruta de asignación caliente ya había aparecido en los perfiles durante algún tiempo, y el autor había intentado previamente el mismo enfoque en #155714.
Análisis de flujo de datos
PR #160193 alteró el algoritmo de recorrido del CFG empleado por los análisis de flujo de datos del compilador, que iteran hasta un punto fijo y dependen del algoritmo de recorrido para su velocidad de convergencia.
En la mayoría de los casos, el nuevo algoritmo no produce ningún cambio. Una excepción es el crate cranelift-codegen, que contiene una única función enorme con más de 18,000 bloques básicos. Con el enfoque anterior, alcanzar un punto fijo para el análisis EverInitializedPlaces utilizado por el borrow checker requería 1.5 millones de llamadas a apply_effects_in_block. El nuevo algoritmo reduce esa cifra a 90,000, lo que supone una importante reducción de ~30% en el tiempo de ejecución para una compilación de este crate.
Otra PR más tarde restauró EverInitializedPlaces a una mayor eficiencia, dejando de rastrear datos que no eran necesarios para las proyecciones. Ese cambio redujo el número de instrucciones en el benchmark match-stress en un 17%, y en algunos otros benchmarks en menos de 1%.
Tamaño de pila y Rollups
El tamaño de pila predeterminado del compilador fue aumentado por Chris Denton, lo que hizo posible eliminar ensure_sufficient_stack, una función manual de extensión de pila que había sido dispersa en lugares donde era probable que hubiera recursión profunda. Mucha conversación rodeó este cambio, ya que decidir cómo manejar el agotamiento de la pila no siempre es fácil.
Los resultados muestran ganancias reales, con menos instrucciones necesarias en una amplia gama de pruebas, algunas mostrando reducciones cercanas al 3%.
El proyecto también utiliza muchos PRs de «rollup», donde múltiples PRs se combinan en conjunto. Esto se debe a que el equipo no tiene suficiente capacidad de CI para combinar todo por separado.
El LLM Assist
Varios de los PRs referenciados en la publicación se beneficiaron del soporte de análisis LLM, lo que el autor encontró útil. Estos sistemas se han vuelto muy hábiles en formas particulares de análisis, aunque siguen siendo completamente autosuficientes cuando se trata de escribir su propio código y texto. Esa independencia es primordial, y también se adhiere a la política declarada del proyecto.
La declaración final del informe dice que «el mar de verde» demuestra cómo las regresiones de Polonius Alpha se perdieron entre todas las otras mejoras recientes.
Lo que esto significa
El tamaño del proyecto define su alcance. Seiscientos veintinueve pruebas de referencia, una reducción promedio del tiempo de ejecución del 4.57%, 555 mejoras entre 629 — estas son cifras sustanciales. El equipo del compilador ha producido ganancias reales y medibles en decenas de PR, donde las pérdidas fueron superadas por los éxitos.
El documento describe a un grupo que opera a toda velocidad, presentado como un registro directo en lugar de una pieza promocional. Incluye admisiones de fracaso, como el esfuerzo anterior de despacho estático en #155714, que provocó regresiones, junto con relatos de logros. Esta franqueza contribuye al poder del documento.
Tanto la narrativa de Polonius como la de Penelope ofrecen lecciones útiles. Cada uno de estos nuevos métodos es más lento en algunas situaciones, pero ambos se están refinando con un esfuerzo concentrado. El problema de la crate serde, por ejemplo, se resolvió a través de los cálculos de liveness perezosos de Jack Huey.
Un compilador es una pieza de maquinaria complicada, y acelerarlo requiere cambiar casi todas sus partes. Durante más de dos meses, el equipo ha estado llevando a cabo ese trabajo, y los resultados son visibles. El «mar de verde» es más que una frase — proviene de cientos de pruebas de referencia que se ejecutaron para medir las mejoras.
La observación final apunta a un mayor progreso en el solucionador de rasgos, citando el exhaustivo trabajo de Jana Dönszelmann. Esto implica que el ritmo se mantendrá.
| Rango de fechas | Ejecuciones de referencia | Reducción promedio del tiempo de ejecución |
|---|---|---|
| 2026-07-29 a 2026-09-28 | 629 | 4.57% |
Surge una imagen clara de un grupo que comprende su oficio, con el compilador volviéndose más eficiente y sus constructores registrando sus esfuerzos con cuidado.
Material fuente: “Cómo acelerar el compilador de Rust en septiembre de 2026,” nnethercote.github.io.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.