Índice de contenidos
Claves de la noticia
- El balance de septiembre de Rust registra una reducción media del 4,57 % en el tiempo de compilación durante dos meses.
- Mejoran 555 de 629 mediciones; el resultado agregado convive con 74 regresiones y no garantiza acelerar cualquier proyecto.
- Los cambios combinan optimización de herramientas y algoritmos con nuevos comprobadores activados en el canal experimental nightly.
Nicholas Nethercote ha publicado este 30 de septiembre un balance del rendimiento del compilador de Rust que permite medir el progreso acumulado entre el 29 de julio y el 28 de septiembre. La reducción media del tiempo transcurrido es del 4,57 %. El informe documenta mejoras amplias, pero también casos que empeoran. Su interés práctico está en explicar qué trabajo se ha eliminado y qué cifras puede esperar trasladar un equipo a su propio proceso de desarrollo.
El 88,2 % de las mediciones mejora
El recuento comunicado por el mantenedor contiene 555 mejoras y 74 regresiones, un total de 629 mediciones. Al dividir cada grupo por el total, el cálculo propio da aproximadamente un 88,2 % de resultados favorables y un 11,8 % desfavorables. Es una forma más precisa de describir la amplitud del avance que convertir la media en una promesa para todos los usuarios.
La unidad contada es una medición del banco de pruebas: no una empresa, un desarrollador ni necesariamente un proyecto diferente. Por eso el porcentaje no significa que el 88,2 % de las aplicaciones de Rust vaya a compilar más deprisa. Tampoco mide la velocidad con la que se ejecutan los programas obtenidos. El compilador y el producto que genera tienen costes distintos.
El repositorio oficial de rustc-perf explica la infraestructura que sostiene estas comparaciones: un recolector reúne datos de las integraciones del proyecto y el sitio permite consultarlos, además de solicitar pruebas mediante un bot de GitHub. Esa trazabilidad importa porque una cifra de compilación depende del perfil de construcción y de la carga que se analiza.
Un recorrido distinto elimina trabajo repetido
La solicitud de cambio 160193, integrada el 1 de agosto, ofrece un ejemplo concreto. Cambia el orden de recorrido del grafo de control durante los análisis de flujo de datos. Estos análisis repiten operaciones hasta alcanzar un estado estable; procesar un bloque antes de que sus entradas se hayan asentado puede obligar a recorrerlo otra vez.
El cambio sustituye la cola anterior por un algoritmo que atiende primero el bloque pendiente situado antes en el orden del análisis. La documentación del compilador sitúa estas comprobaciones dentro de su trabajo sobre representaciones intermedias: verificar el código requiere resolver tipos, relaciones y estados antes de producir el ejecutable.
La evidencia más llamativa aparece en una función de cranelift-codegen con 18.073 bloques básicos. La instrumentación publicada en la conversación de GitHub reduce las llamadas del análisis EverInitializedPlaces de 1.508.264 a 89.809. Dividir ambos valores muestra unas 16,8 veces menos llamadas, equivalentes a una reducción aproximada del 94,0 % en esa operación concreta.
La conclusión tiene un límite decisivo: eliminar el 94 % de llamadas de una fase no elimina el 94 % de toda la compilación. El resto del trabajo continúa existiendo. La misma conversación registra una mejora cercana al 33 % en tiempo en el mejor caso de cranelift-codegen y advierte de posibles fluctuaciones en otros resultados. El cuello de botella explica una ganancia localizada, no una aceleración universal de esa magnitud.
Clippy y LLVM actúan en capas diferentes
Otro frente es Clippy, la herramienta que detecta errores habituales y propone mejoras al código. La solicitud 159642, integrada el 21 de agosto, incorpora optimización guiada por perfiles, o PGO, a la construcción de la propia herramienta. No exige que cada aplicación del usuario haya sido preparada con ese procedimiento para entender el cambio.
La documentación de rustc describe PGO como una secuencia de instrumentación, ejecución con cargas representativas, combinación de perfiles y nueva compilación usando esos datos. Las rutas utilizadas con frecuencia ayudan a orientar decisiones como la disposición del código o la expansión de funciones. Aplicar el procedimiento a Clippy busca reducir el coste de ejecutar sus comprobaciones.
La actualización a LLVM 23 pertenece a otra capa. La solicitud 158734 se integró el 5 de agosto y también recoge ajustes de pruebas, dependencias y compatibilidad por plataforma. LLVM participa en la generación de código; cambiarlo puede alterar tiempo, memoria y tamaño del resultado de maneras distintas. Sumar porcentajes de Clippy, LLVM y una comprobación aislada produciría un dato sin significado: no son mejoras independientes medidas sobre el mismo trabajo total.
Dos cambios de agosto siguen bajo prueba
La cronología oficial añade contexto al balance. El 4 de agosto el proyecto anunció Polonius Alpha en nightly, su canal experimental, para probar una nueva iteración del comprobador de préstamos. Permite reconocer relaciones de duración de referencias según el camino que sigue el programa y aceptar determinados casos válidos que el análisis anterior rechazaba.
El 21 de agosto se anunció también en nightly el nuevo solucionador de traits, encargado de comprobar requisitos del sistema de tipos. El proyecto explicó que reemplaza una parte profunda del compilador, corrige numerosos problemas y necesita localizar incompatibilidades, regresiones y diagnósticos deficientes antes de estabilizarse. Ninguno de esos anuncios convierte el informe de hoy en el lanzamiento de una versión estable nueva.
Para los equipos que mantienen aplicaciones, la mejora media y el coste de estas comprobaciones deben leerse juntos. Un resultado agregado favorable puede coexistir con una dependencia concreta más lenta. Conviene contrastar compilaciones limpias, incrementales y comprobaciones del proyecto real, conservando la versión de herramientas y el entorno de prueba.
La distinción también evita confundir este avance con el cambio del runtime de Copilot a Rust: aquel caso mide comportamientos de una aplicación; este trata del coste de construir y analizar código. El balance aporta una conclusión operativa: Rust ha acelerado ampliamente su banco de compilación mientras renueva comprobadores centrales, pero decidir una actualización exige medir el flujo de trabajo que importa a cada equipo.
