¿Por qué es tan lento el CI?

Hola a todos. Mi nombre es Nicholas. Soy un desarrollador de software en Rome Tools y me gustaría hablarles a todos sobre por qué su CI es tan malditamente genial. Todos hemos estado ahí. Has subido tu último código a GitHub, tu servicio de CI está funcionando y está tardando una eternidad. Esperas y esperas y esperas, solo para obtener el resultado 5, 10, incluso 20 minutos más tarde. Es molesto, es disruptivo, es una pérdida de tu maldito tiempo. Normalmente, simplemente aceptamos esto como una verdad eterna. El CI es genial. No creo que eso esté bien. Tener que esperar por el CI tiene un efecto directo y negativo, tanto en tu productividad como en tus finanzas. Comencemos con un recurso que nos importa a todos. El tiempo del desarrollador. No sé ustedes, pero cuando me encuentro con una sincronización de tiempo como un CI lento, hago una de dos cosas. Me relajo o comienzo otra tarea. Holgazanear claramente es negativo. Claro, todos merecemos descansos, pero no cada vez que subimos código. Nuestro CI no debería determinar cuándo trabajamos o no. Pero Nick, podrías simplemente comenzar otra tarea. Y sí, comenzar otra tarea parece tentador. Todos somos capaces de hacer varias tareas a la vez. Resulta que no, no lo somos. En el artículo, Interrupción de tareas en proyectos de desarrollo de software, los autores midieron el efecto del cambio de tarea en la productividad. No fue bueno. En particular, señalaron que las auto-interrupciones, básicamente cuando cambias de tarea a propósito, tienden a ser más disruptivas que las interrupciones externas y conducen a una menor finalización de tareas. Con un CI lento, este flujo se interrumpe constantemente. Terminas cambiando entre los trabajos de CI y tu nueva tarea, perdiendo tu contexto de trabajo y, por lo tanto, tu eficacia y eficiencia. O peor aún, te enfocas en tu nueva tarea, te olvidas de tu trabajo de CI y solo recuerdas unas horas después de que tu trabajo está hecho. Le envías un mensaje a tu revisor solo para darte cuenta de que se ha ido a casa. De repente, un PR rápido tarda dos días o más en fusionarse.

Aún peor es cuando tienes que depurar un flujo de trabajo de CI. Cada vez que tengo que depurar uno, es tan horrible. Terminé ajustando una configuración, esperando a que el trabajo se complete, distrayéndome, y solo viendo los resultados 15 minutos después. Un ciclo de desarrollo de 15 minutos no es aceptable en esta época. Pero no solo se trata del tiempo del desarrollador. Un CI lento significa más tiempo de cálculo, lo que, como cualquiera que haya mirado con asombro su factura de AWS sabe, significa más dinero. Un ejemplo de esto es la instancia gratuita de GitLab en el escritorio, que alberga una serie de proyectos de software gratuitos, como Mesa, los controladores del kernel de Linux y muchos otros. Experimentaron un período masivo de crecimiento a finales de 2019 y principios de 2020. Sin embargo, sus gastos aumentaron en consecuencia, primero a $75,000 en 2019. Y luego se proyectaba que alcanzarían los $90,000 en 2020. Lograron reducir los costos antes de quedarse sin dinero, pero aún así, para un proyecto de código abierto, eso es una cantidad enorme para gastar en CI. Hagámoslo mejor. Vamos a averiguar por qué el CI es lento. Para hacerlo, debemos analizar qué hace un trabajo de CI. En su núcleo, hay dos tipos de trabajos de CI, trabajos estáticos y trabajos dinámicos. Los trabajos estáticos aplican herramientas de desarrollo, como un Linter, Bundler, Formateador, etc., a tu código sin ejecutarlo. Los trabajos dinámicos también pueden aplicar herramientas, pero deben ejecutar tu código. Nos vamos a centrar en los trabajos estáticos pero muchas de estas lecciones también se aplican a los trabajos dinámicos. En cualquier caso, si tu trabajo de CI es lento, es probable que tus herramientas sean lentas. Pero ¿qué quiero decir exactamente con lento? Por supuesto, me refiero a que las herramientas son lentas en su tiempo de ejecución. Sin embargo, para el CI, hay un segundo tipo de lentitud. Estas herramientas también son lentas en su tiempo de instalación. Tomemos ESLint. Es una gran herramienta. Sin embargo, al igual que muchas herramientas en el ecosistema de JavaScript, tiene muchas dependencias. Esto no es una charla para avergonzar a las dependencias. Yo uso dependencias. Tú usas dependencias.

Con todo esto en mente, ¿cómo se ve nuestro trabajo ideal de CI? En el caso de trabajos estáticos, estos trabajos deberían funcionar como programas nativos sin JavaScript runtime involucrado. No hay realmente ninguna razón para ejecutar Node o Docker para un linter o bundler. Se pueden usar como una línea de comandos o como una API. En ese caso, la expectativa de performance debería ser igual a cualquier otra API REST. Lo llamas, obtienes un resultado en menos de un segundo. Por supuesto, para trabajos dinámicos, donde necesitamos ejecutar el código, aún podemos iniciar un runtime. Pero tal vez podamos optar por entornos más livianos. Algo como un AWS Lambda o un CloudFlare worker podría ser suficiente.

Entonces, ¿dónde encaja Roam en esto? Por ahora, nos enfocamos en ofrecer herramientas rápidas y nativas de JavaScript. Nuestro plan a largo plazo es ser la solución integral para todo JavaScript. Esperamos que en el futuro, estas herramientas sean el reemplazo para trabajos estáticos de CI. Pero, ¿por dónde empezamos? Por supuesto, no podríamos abordar todas las herramientas simultáneamente. Decidimos investigar, mirar repositorios de código abierto y ver qué era lento en su configuración de herramientas. Descubrimos que el linting generalmente era bastante lento. Pero en particular, una regla se destacaba: prettier. Si no estás familiarizado, hay una regla de ES lint que verifica si tu código está formateado correctamente ejecutando prettier en tu código y viendo si hay algún cambio. En el caso de Babel, un compilador de JavaScript originalmente escrito por el fundador de Roam, Sebastian, la regla de ES lint de prettier tarda más de seis segundos en completarse. Con Webpack, esta regla tarda cinco segundos. Puedes estar diciendo en este punto, ¿seis segundos? Eso no es mucho. Y estaría de acuerdo en abstracto. Pero en realidad, seis segundos marcan la diferencia entre ejecutar tu linter como un observador local y ejecutarlo en CI. Si tarda seis segundos en obtener los resultados del linter, es probable que no integres el linter en tu flujo de desarrollo. Probablemente no quieras llamarlo a través de una API REST. En cambio, confiarás en ejecutarlo como una tarea de CI. Esperarás más tiempo antes de ver posibles problemas en tu código.

No me malinterpretes. Me encanta prettier, pero puede volverse notablemente lento en archivos grandes. En particular, nos inspiramos en el formateador de Rust, que es súper rápido. Decidimos que queríamos un formateador del mismo nivel de rendimiento, pero para JavaScript. También queríamos un formateador que estuviera integrado en tu entorno de desarrollo.

Una característica particular de las herramientas para desarrolladores que nos encanta se llama tolerancia a errores. Una herramienta es tolerante a errores si funciona incluso cuando tu código tiene errores, ya sean sintácticos o semánticos. Trabajamos mucho para hacer que el formateador sea tolerante a errores. De esa manera, puede hacer que tu código se vea bien sin importar qué.

Estamos súper emocionados de anunciar que nuestro formateador se lanzará el 28 de marzo. Nos encantaría mostrar un adelanto del rendimiento de nuestro formateador. Primero, tenemos Dojo, un framework front-end. Ejecutando el formateador en una biblioteca empaquetada, prettier tarda 75 milisegundos, lo cual no está mal, pero roam está en solo 10 milisegundos. Para Svelte, prettier tarda hasta 750 milisegundos, casi un segundo, mientras que roam está en solo 200 milisegundos. Y finalmente, está el gigante que es el archivo checker.ts de TypeScript, con más de 44,000 líneas, o 2.64 megabytes. No sé si alguna vez has abierto este archivo en un editor, pero te diré ahora, ralentiza mi editor hasta hacerlo casi inusable. Prettier tarda más de dos segundos en formatear este archivo. Nosotros lo hacemos en 335 milisegundos.

Pero eso es solo el comienzo. Nuestro próximo objetivo es el winting. Como mencioné antes, el winting es bastante lento en JavaScript. ESLint puede tardar fácilmente 15, 30 segundos en ejecutarse en una computadora potente. Queremos ser una décima parte de eso. El winting también aprovechará el poder de nuestro Árbol de Sintaxis Concreta o análisis basado en CST. Una vez más, si estás familiarizado con los compiladores, sabrás que los analizadores generalmente producen lo que se llama un Árbol de Sintaxis Abstracta o AST. Los AST son geniales porque abstraen detalles innecesarios, como espacios en blanco o comentarios. Sin embargo, resulta que estos detalles supuestamente innecesarios son bastante importantes para otras herramientas para desarrolladores. Específicamente, es realmente difícil hacer algo como analizar el código en un AST, modificar el AST y luego convertirlo nuevamente en código sin reorganizar por completo el código, creando así una gran diferencia en git. Con un CST, todo se preserva. Comentarios, espacios en blanco, todo.

Eso significa que convertir un CST de vuelta a código con solo una diferencia mínima es extremadamente fácil, lo que a su vez abre un conjunto completo de potentes funciones de modificación de código. Estamos muy emocionados de demostrar las posibilidades del linting basado en CST. Nuestro linter estará disponible a finales del segundo trimestre y estamos muy emocionados de demostrar las posibilidades del linting basado en CST entre diferentes lenguajes.

Para resumir, CI es lento porque nuestras herramientas son lentas, tanto en el tiempo de instalación como en el tiempo de ejecución. Son lentas porque utilizan lenguajes más lentos que dependen de tiempos de ejecución y containers. Para hacer que CI sea más rápido, necesitamos herramientas nativas rápidas para JavaScript.

Si estos objetivos te parecen interesantes, pronto estaremos contratando. No dudes en ponerte en contacto con Nicholas en RoamTools.com o a través de Twitter. Gracias.

Sí, una charla realmente genial y Nicholas, gracias por compartir eso con nosotros. En realidad, fue una charla bastante rápida sobre lo lento que es CI, ¿verdad? Sí, no quería hacerte perder el tiempo. Pero fue buena. Pero has desempaquetado mucho ahí, así que buena charla. Echemos un vistazo a nuestros resultados de Slido. Estoy muy intrigado por saber qué piensa la gente. ¿Cuál es la herramienta más lenta y molesta? Vamos a verlo juntos. Entonces, Bundler, el 50% dice Bundler. Vale, eso es interesante. Pero en segundo lugar, tenemos el IDE. Así que si quieres compartir en el chat qué IDE estás usando, nos encantaría saber cuáles estás usando y cuáles encuentras bastante lentos. Y a menos que eso sea como etcd allí, me encantaría desempaquetar también el etal o et cetera para saber qué está en tercer lugar. Qué está en tercer lugar, así que cuéntanos qué otras herramientas crees que no están en la lista. Nos encantaría saber sobre ellas. Y sí, escuchemos qué preguntas tenía la gente, Nicholas. Comencemos con algunas de las preguntas y respuestas.

Muy bien, genial. Entonces, comencemos con ¿qué pasa con las pruebas? ¿No hay problemas inherentes de rendimiento con las pruebas? Sí. Estoy de acuerdo con eso. Diría que las pruebas son, sin duda, lo que hace que CI sea más lento, y hay un límite inherente en las pruebas que son simplemente código que debes ejecutar. Pero creo que hay posibles soluciones en esta área.

Por ejemplo, puedes reducir considerablemente la sobrecarga de tiempo de ejecución. Puedes utilizar algo como una curva de trabajo optimizada para tener una rápida aceleración y un inicio rápido. También puedes investigar posibles optimizaciones dentro de JavaScript. Tal vez puedas hacer que JavaScript se ejecute más rápido. Tal vez puedas encontrar formas de precompilar JavaScript. Creo que, sabes, lo hemos estado tratando como una caja negra. Pero creo que hay posibilidades que realmente podemos utilizar para hacer que CI sea un poco más rápido y más receptivo.

Sí, en cuanto a las pruebas, estoy de acuerdo. Creo que hay mucho que se puede hacer para optimizar. Entonces, en las pruebas, me pregunto cuáles son las otras tareas pesadas en ese proceso.

Sí, diría que las pruebas. El benchmarking es otro clásico, porque, nuevamente, con el benchmarking, tienes que ejecutar el código y mantenerlo. A menudo tienes que ejecutar el código varias veces. Muchos frameworks modernos de benchmarking realizan análisis estadístico. Por lo tanto, tienen que ejecutarlo un número estadísticamente significativo de veces. Y, ya sabes, si no hay una solución tan buena porque, nuevamente, es benchmarking. Pero creo que hay algunas técnicas que podemos tomar de grandes empresas. Por ejemplo, sé que en Facebook, solo ejecutan benchmarks y pruebas relevantes para el commit. Porque obviamente Facebook se ejecuta a la escala de Facebook y no se pueden ejecutar todas las pruebas que existen. Así que creo que realmente... Estamos muy emocionados de ver cómo otras personas abordan este problema. Y también estamos muy emocionados de mostrar a las personas nuestras soluciones a este problema.

Genial. Entonces, Sissy Miller pregunta, viniendo del mundo de PHP, Pest PHP está revolucionando el mundo de las pruebas allí y está haciendo que las pruebas sean mucho más rápidas. Pero le gustaría preguntar, o no, él o ella, no lo sé. ¿Estarías de acuerdo en que parte de la lentitud de CI se puede evitar con un código más limpio? Yo diría que sí. Por supuesto. Creo que, tanto un código más limpio en las herramientas como en tu código normal. Obviamente, si estás ejecutando el código, quieres que sea rápido y no lento. Y diría, desde mi perspectiva, como alguien que escribe herramientas, creo que eso es algo que se ha descuidado en el mundo de las herramientas: el rendimiento.

Y, sabes, me gustaría hacer una mención especial a muchas personas que están escribiendo herramientas y que piensan en el rendimiento de manera cuidadosa, como los autores de ESBuild y los autores de SWC. Nosotros en Roam, hemos puesto mucho esfuerzo en eso. De hecho, en realidad... Los benchmarks que les mostré en la charla están realmente desactualizados. Hemos estado haciendo muchas optimizaciones de rendimiento desde entonces, y diría que nuestros números son quizás un 20% o 30% mejores que eso, lo cual es un trabajo realmente fantástico. Y estoy muy emocionado de mostrar eso a la gente. Creo que, ya sabes- Eso es realmente genial. Sí, siempre hay más cosas que se pueden hacer. Siempre hay más rendimiento que se puede exprimir. Así que sí.

Solo, supongo, compartir un poco. ¿Qué tipo de mejoras de rendimiento has implementado en Roam? Solo de lo que te acuerdes. Por ejemplo, una gran cosa que siempre tienes que hacer es analizar el código. Y el análisis es notoriamente lento por varias razones. Primero, tienes que leer el código de E/S. Y segundo, tienes que crear esta gran estructura de datos. Así que hemos estado trabajando mucho para básicamente asegurarnos de que cuando analices, estés haciendo la cantidad mínima de trabajo porque muchas veces puedes analizar algo y luego darte cuenta de que es una construcción sintáctica diferente. Por ejemplo, puedes estar analizando, tu analizador puede estar analizando algún código y darte cuenta, oh, espera un momento, no es una expresión JSX, es una aserción de tipo TypeScript. Porque resulta que estas dos cosas se ven muy, muy similares. Y hemos estado trabajando mucho en ese proceso donde el analizador se da cuenta de que es algo diferente a lo esperado. Tiene que retroceder. Estamos tratando de hacer eso menos y menos para que el análisis sea mucho, mucho más rápido.

También estamos trabajando mucho en el formateo, asegurándonos de que el formateador haga solo lo mínimo necesario. Y realmente no está haciendo trabajo redundante moviendo el texto y reorganizando el código.

Bueno, veo eso, gente, solo quiero animarlos a recordar sobre Slido, si quieren decirnos qué otras herramientas encuentran molestas y lentas, nos encantaría escuchar del 11% de ustedes. Y también qué IDE están usando. Nos encantaría saberlo. Y si responden a tiempo, tal vez Nicholas pueda darnos su opinión sobre por qué cree que esas herramientas específicas son lentas. Pero, quiero decir, desde mi perspectiva personal, no encuentro mi CI muy lento. Entonces, ¿por qué esto debería importar? ¿Por qué debería preocuparme por esto? Ese es un buen punto. Y, sabes, me alegra que tu CI no sea lento. Me alegra que, ya sabes, no estés esperando como otras personas. Diría que creo que las herramientas rápidas son universalmente algo bueno, incluso si no es para tu CI. Creo que, ya sabes, realmente, nuevamente debemos recordar que no todos están ejecutando, ya sabes, una computadora súper moderna. Como dije en la charla, ya sabes, nosotros, como desarrolladores en, ya sabes, empresas, obtenemos, ya sabes, hardware moderno, con bastante frecuencia. Pero, ya sabes, hay muchas personas por ahí que están comenzando, o tal vez en empresas que no tienen presupuesto y están ejecutando en hardware más lento y tenemos que adaptarnos a ellos. Creo que no es justo escribir código que solo funcione en, ya sabes, una nueva MacBook Pro. Tiene sentido. Eso es, ya sabes, sí. Sí, puedo apreciar eso, obviamente. Así que eso fue hablado desde lo más profundo de Turbulent.

Eso fue una de esas cosas, y yo pensé, vale. Sí, quiero decir, también he sido culpable de eso. Sabes, ejecuto el código y pienso, oh, es muy rápido, pero, sabes, creo que olvidé qué compañía era, pero tenían la costumbre de básicamente ralentizar su conexión a Internet, como limitarla con el propósito expreso de adaptarse a personas que están en, como, una conexión 3G o incluso 2G, porque creo que es una lección realmente, sabes, importante para dar a los desarrolladores.

Sí, eso es muy cierto. Dainy pregunta, ¿puedes compartir algunos detalles sobre el Linter? ¿Cómo se comparará con ESLint en términos de reglas, complementos y otros factores? Sí, estoy realmente emocionado por esto porque el Linting es algo que, sabes, ha sido lento durante un tiempo. Y obviamente, ESLint es un proyecto fantástico, y tienen muchas reglas, y no voy a decir que vamos a capturar todas estas reglas de una vez, porque, sabes, como todos siempre me dicen todo el tiempo, Roma no se construyó en un día. Así que diría que nos estamos enfocando en cuáles son las reglas más lentas en ESLint, qué cosas realmente lo hacen doloroso, y luego vamos a construir un Linter para esas reglas específicas. Y luego, sabes, la idea tal vez es que puedes ejecutar nuestro Linter, obtener comentarios rápidos para ciertas cosas. Y si quieres una configuración completa de Linting, aún puedes ejecutar ESLint, y aún puedes obtener todos los comentarios de ESLint, pero obtendrás los comentarios rápidos primero.

Eso es genial. Entonces, Nicholas, alguien, J. Reid, está diciendo, Nicholas mencionó que algunas de las varias herramientas en el ecosistema de JS, el ecosistema de JavaScript, tienen que construir sus propios AST. Disculpas, no sé qué significa AST, para hacer su trabajo. ¿Alguien sabe si hay alguna colaboración entre algunas de las herramientas más populares con el objetivo de compartir un solo AST? Solo dime qué es un AST rápidamente. Árbol de Sintaxis Abstracta. Sí, es lo que el analizador produce. Sí, y que yo sepa, no creo que haya. Quiero decir, podría estar equivocado, y estoy dispuesto a que me demuestren lo contrario, porque creo que sería un gran proyecto. Una cosa que encuentro realmente inspiradora es el Proyecto TreeSitter, que es un analizador que básicamente puede analizar varios lenguajes diferentes, prácticamente cualquier lenguaje que puedas pensar tiene un analizador de TreeSitter, incluido JavaScript. Y eso es un gran ejemplo de básicamente alguien escribiendo un gran analizador, que luego muchas personas pueden usar. No estoy muy seguro si actualmente hay alguna forma de compartir el AST. Quiero decir, obviamente hay algunos problemas con si una herramienta cambia el AST, entonces las otras herramientas no pueden usar el mismo AST. Así que es un poco complicado. Y no estoy seguro de que eso funcionaría necesariamente sin algunos cambios importantes. Genial. Gracias. Esa fue una... esa fue una muy buena respuesta. Cece Miller hace otra pregunta. ¿Has investigado sobre la interpretación de código por IA, como GitHub Copilot? Tal vez esto podría llevarlo a otro nivel.

Personalmente, he probado ambos. También soy un gran fan de Tab 9 y Copilot. Creo que son proyectos realmente geniales. Sí, Tab 9 es un proyecto fantástico. No diría que esa es necesariamente la dirección que estamos tomando en Roam en este momento. Creo que definitivamente es algo que estamos abiertos a explorar en el futuro. Quiero decir, creo que la combinación de aprendizaje automático y código es un área realmente fascinante que sin duda se desarrollará más en los próximos años.

Creo que una cosa en la que hemos investigado y que he estado considerando es tal vez utilizar el aprendizaje automático para la recuperación de errores del analizador. Como mencioné en la charla, una gran ventaja de nuestro analizador es que tiene una muy buena recuperación de errores. Básicamente, puede detectar cuando hay un error e intentar adivinar qué quisiste decir con eso. Y actualmente lo hacemos con algunas heurísticas, pero creo que en el futuro podría ser una oportunidad realmente interesante para el aprendizaje automático donde puedes utilizar conjuntos de datos de código incorrecto para estimar cuál es el código previsto y luego ofrecer una corrección o un mejor análisis semántico. Sí, eso tiene sentido. Forlex, no sé si es Forlex o si es Leap para Alex, pero pregunta cómo se manejarán todas esas reglas personalizadas del linter que vienen con otras bibliotecas de forma gratuita como lint, ¿cómo las van a soportar? Esa es una muy buena pregunta. Voy a ser honesto, todavía estamos tratando de resolver eso nosotros mismos. Creo que, nuevamente, tenemos esta idea de que R12 es como el explorador que va un poco adelante. Y, ya sabes, si nuestras reglas son incorrectas debes corregirlas primero. Y luego, si nuestras reglas son todas, ya sabes, válidas y el código es correcto para estas reglas entonces puedes ejecutar eswint y obtener la completitud total. No, ya sabes, creo que haremos nuestro mejor esfuerzo para ofrecer una amplia variedad de reglas y seguiremos agregando más pero la realidad es que eswint, ya sabes, hace un trabajo maravilloso y también es una comunidad muy próspera. Y, ya sabes, tenemos que reconocer eso. Sí. Genial. Estás recibiendo comentarios realmente buenos aquí. Solo quiero decirte que lo que piensa la comunidad son ideas realmente buenas de tu compañero en la sala de discusión, en la sala de construcción, Ante Tomić. Ideas realmente buenas. Está interesado en Rome, quiere echarle un vistazo y hay muchos comentarios realmente buenos sobre la charla. No veo, ahora es el momento, esto es todo. Estamos llegando al final. Haz tus últimas preguntas a Nicholas. De lo contrario, nos uniremos a Nicholas y a nuestros compañeros presentadores para una breve charla junto al fuego.