- incident.io tomó como criterio el tiempo de build de Go, no la sensación subjetiva, para decidir si cambiar las laptops de desarrollo a M3, y recopiló datos reales del ciclo de retroalimentación en desarrollo local
- Como era difícil obtener los valores necesarios con el hot reloader de Go existente, crearon una herramienta propia y cargaron al data warehouse eventos de build como plataforma, memoria, estado de energía, etapas del build, archivo que lo disparó y tiempo total
- De unos 25k builds, filtraron los fallidos, cancelados y los ejecutados con batería, y analizaron 12,525 builds exitosos, confirmando una diferencia estadísticamente significativa a favor de los builds conectados a corriente alterna frente a los de batería
- Como resultado, los usuarios de M1 a menudo esperaban casi 2 minutos para completar un build; M2 mostró una gran mejora frente a M1, mientras que M3 mostró una mejora gradual frente a M2
- Aunque en el tiempo total de build la diferencia de memoria no fue tan clara, en el tiempo del linker sí favoreció a los equipos con 32~36GB, por lo que incident.io decidió reemplazar los equipos M1 por M3 Pro base con 36GB
El criterio para decidir la actualización fue el ciclo de retroalimentación del desarrollo
- Todos los desarrolladores de incident.io usan MacBook para su trabajo de desarrollo
- Después de que Apple presentó la MacBook Pro con M3 en octubre de 2023, el CTO Pete dijo que harían el cambio si el valor de la actualización se demostraba con datos
- Para decidir si valía la pena actualizar a M3, el equipo preparó tres cosas
- Un hot reloader de Go personalizado
- Recolección de telemetría de builds en las laptops de desarrollo
- Análisis de datos usando el modelo más reciente de OpenAI y el intérprete de código
- Aunque es difícil cuantificar directamente la productividad de los desarrolladores, en incident.io consideran que un ciclo de retroalimentación rápido es clave para la eficiencia
- En el desarrollo local, los ciclos de retroalimentación que se repiten con frecuencia son los siguientes
- Compilación del monolito en Go
- Generación de código, como clientes de API e interfaces
- Hot reload del frontend y de la app móvil
- Los desarrolladores de incident.io ejecutan todo el entorno de incident.io localmente en sus laptops y mantienen un ciclo de retroalimentación de menos de 30 segundos entre un cambio de código y su ejecución
- La app en Go se está acercando a casi 1 millón de líneas de código, por lo que eligieron la compilación de Go, que ocurre con frecuencia y tiene un costo alto, como métrica para comparar el rendimiento de las MacBook
Cómo recopilaron la telemetría de builds
- incident.io ha usado codegangsta/gin como hot reloader de Go desde la creación inicial del repositorio en GitHub
- Evaluaron otros hot reloaders, pero no encontraron una herramienta que ofreciera la telemetría necesaria para analizar los tiempos de build
- Los datos que querían recopilar en cada build eran los siguientes
- A nivel de sistema: plataforma M1/M2/M3, memoria total, etc.
- Métricas de runtime: sistema operativo, uso de memoria, fuente de energía, nivel de batería, etc.
- Telemetría de build: duración total, etapas del build de Go, archivo que disparó el build, etc.
- Como no había una alternativa lista para usar, crearon su propia herramienta a partir de
main.go, ejecutando y parseando la salida de varios binarios de Mac para extraer los valores necesariosmemory_pressuredockersysctlpmset
- El código relacionado está publicado como Gist
- Después de crear los recolectores de sistema y runtime, envolvieron el comando de build de Go para recolectar tiempos por etapa, como linker y compilación, así como el archivo que disparó el build
- El hot reloader final se ejecutaba desde el objetivo existente
make run, y fue un cambio invisible para el equipo de ingeniería - Al terminar cada build, enviaban un evento de telemetría a un endpoint HTTP y lo cargaban al data warehouse mediante un receptor de webhooks de Fivetran
Flujo de análisis con OpenAI Assistant
- Tras reunir un dataset suficiente durante varias semanas, exportaron desde BigQuery el resultado de
select * except(payload) from developer__build_eventsa un CSV - Proporcionaron a OpenAI Assistants un prompt que explicaba el objetivo y el archivo CSV
- Activaron el modelo experimental
gpt-4-1106-previewy el intérprete de código para el análisis de datos - El tiempo de build varía mucho incluso en el mismo sistema, y el impacto del caché del compilador de Go también es grande, por lo que comparar solo los promedios por plataforma no sería justo
- Una M3 Max sin caché podría ser más lenta que una MacBook Intel antigua con caché
- El análisis no se hizo comparando promedios simples, sino ordenando las condiciones del build y separando por plataforma, memoria y estado de energía
Limpieza de datos y condiciones de comparación justa
- El dataset completo tenía alrededor de 25k builds y se recopiló en diferentes horas del día, laptops y condiciones
- Para comparar plataformas de forma justa, excluyeron los siguientes builds
- Builds fallidos o cancelados: como no se completaron, no eran adecuados para comparar velocidad
- Builds con batería: OS X puede limitar el rendimiento para preservar la duración de la batería
- Después de excluir los builds fallidos, se contabilizaron 12,525 builds exitosos
- La diferencia de rendimiento entre builds con corriente alterna y con batería se comparó principalmente en M1 Pro y M2 Max
- En la prueba estadística, el tiempo promedio de los builds con corriente alterna fue menor, con un p-value de aproximadamente 0.0014
- A partir de ahí, el análisis utilizó solo builds exitosos conectados a corriente alterna
Por qué fluctúa el tiempo de build en Go
- El monolito en Go de incident.io es un objetivo de observación continua para el rendimiento de build, y consideran importante no solo comprar hardware, sino también eliminar y ajustar el propio proceso de build
- Los proyectos en Go están compuestos por varios paquetes, y el compilador de Go usa caché para recompilar solo los paquetes que considera modificados
- La app de incident.io está diseñada con un grafo de dependencias amplio y pocos módulos base, para que la mayoría de los cambios no obliguen a recompilar todo el grafo
- Los tipos de build se dividen aproximadamente en cuatro
- Finalización inmediata, menos de 3 segundos: cambios no relacionados con el compilador de Go, donde se puede reutilizar un binario en caché
- Build rápido, menos de 30 segundos: cambio en un solo paquete con pocas dependencias; se reutiliza la mayor parte del caché y el tiempo se va sobre todo en el enlace
- Build intermedio, de 30 segundos a 1 minuto: se modificó un paquete funcional con algunas dependencias inferiores, pero la mayoría sigue siendo reutilizable
- Build lento, más de 1 minuto: se agregó un tipo al paquete base
domainy hay que recompilar todos los paquetes de la app
- La comparación entre plataformas debe considerar estas diferencias en la naturaleza de los builds; mezclar todos los builds sería como comparar peras con manzanas
Resultados de la comparación entre M1, M2 y M3
- Primero compararon M1 Pro y M2 Max considerando solo builds exitosos conectados a corriente alterna
- M2 Max superó claramente a M1 Pro en velocidad de build, pero ambos equipos diferían no solo en el chipset, sino también en la configuración de memoria
- La distribución de eventos de builds exitosos por plataforma y memoria fue la siguiente
- Apple M1 Pro 16GB: 5,235
- Apple M2 Pro 16GB: 1,927
- Apple M2 Max 32GB: 3,842
- Apple M3 Pro 18GB: 321
- Apple M3 Pro 36GB: 899
- Apple M3 Max 36GB: 301
- La comparación entre M1 Pro 16GB y M2 Max 32GB no era del todo justa por la diferencia de memoria
- Al comparar M2 Pro 16GB con M2 Max 32GB, el impacto de la memoria de 32GB en el tiempo total de build parecía pequeño
- M2 Pro y M2 Max son en gran medida el mismo chip, y Max tiene 2 núcleos adicionales de eficiencia energética
- Consideraron que esos núcleos aportan poco a la compilación de programas en Go, ya que rinden alrededor de 1/5 de un núcleo de rendimiento
- Para evaluar M3, compraron tres equipos
- M3 Pro de 12 núcleos, 6 núcleos de rendimiento + 6 núcleos de eficiencia, 18GB
- M3 Pro de 12 núcleos, 6 núcleos de rendimiento + 6 núcleos de eficiencia, 36GB
- M3 Max de 14 núcleos, 10 núcleos de rendimiento + 4 núcleos de eficiencia, 36GB
- Las gráficas de tiempo de build de M3 Pro 18GB y 36GB eran parecidas, pero los datos de M3 eran menos abundantes que los de otras plataformas
- Al comparar M3 Pro y M3 Max excluyendo los builds muy rápidos de menos de 3 segundos, M3 Max no mostró una mejora lo bastante notable como para justificar su precio 60% más alto frente al M3 Pro base
- La conclusión general fue la siguiente
- Los usuarios de laptops M1 a menudo esperan casi 2 minutos para que termine un build
- M2 es una gran actualización frente a M1
- M3 es una mejora gradual frente a M2
- Los usuarios de M1 se actualizan al M3 Pro base
- Los usuarios de M2 no necesitan actualizarse
La memoria se nota más claramente en el tiempo del linker
- En la comparación del tiempo total de build, no se observó una mejora tan significativa al pasar de 16~18GB a 32~36GB
- Como el efecto de la memoria no aparecía con tanta claridad en la gráfica como se esperaba, analizaron por separado el tiempo del linker dentro de las etapas del build
- Los eventos de telemetría incluían el tiempo de enlace y compilación, y analizaron creando la columna
linker_timea partir debuild_stages.link.duration_seconds - Al comparar
linker_timepor plataforma y configuración de memoria, apareció un patrón distinto- Los equipos M1, M2 y M3 con 32~36GB de memoria casi siempre completaban el enlace en menos de 20 segundos
- En los equipos con 18GB o menos, era frecuente que el enlace superara los 20 segundos
- Confirmaron que agregar memoria, aunque menos claro en el tiempo total de build, sí es útil en la etapa del linker
- También están evaluando eliminar Docker de las máquinas de desarrollo, y de ahí surgió la interpretación de que en equipos con poca memoria, quitar Docker podría aumentar la memoria disponible del sistema y mejorar los tiempos de enlace
- En el desarrollo de la app móvil, el simulador consume mucha memoria del sistema, así que concluyeron que ampliar memoria también se justifica como inversión a futuro
Decisión final y efectos secundarios
- incident.io decidió actualizar los equipos M1 al M3 Pro base con 36GB de memoria
- Los equipos M2 ya parecen tener un rendimiento suficientemente bueno, así que no los actualizarán por ahora
- Además de ayudar a decidir la compra de laptops, esto aumentó su comprensión del entorno y de las herramientas de desarrollo
- Estos fueron los resultados que obtuvo el equipo
- Encontraron en el tiempo de build de Go un buen benchmark para medir el rendimiento de las máquinas de los desarrolladores
- Crearon su propio hot reloader de Go para rastrear las métricas necesarias y obtuvieron otras mejoras de usabilidad
- Entendieron mejor qué factores aceleran o ralentizan los builds en Go
- Confirmaron que OpenAI Assistants puede servir para problemas similares de análisis de datos
- Cuantificaron las mejoras entre las distintas líneas de chips de Apple desde la perspectiva de un desarrollador de Go
- La memoria importa, pero se nota más claramente en el tiempo del linker que en el tiempo total de build
1 comentarios
Opiniones de Hacker News
Es un excelente artículo y me gusta que hayan recopilado y analizado los datos de varias maneras, pero creo que habría sido mucho más fácil y preciso poner las laptops lado a lado y ejecutar builds cronometrados en el mismo escenario.
Probablemente se podría haber creado en un día un script para comparar algunos casos, como un build completo, un build incremental de cambios recientes o un build incremental que requiera recompilar un módulo específico, o para aplicar en orden los últimos 100 commits de Git y medir los tiempos de build incremental.
Si se recopilan estadísticas de toda la empresa, puede introducirse mucho sesgo. Por ejemplo, es más probable que los nuevos empleados usen M3 y los empleados antiguos usen M1; los nuevos suelen hacer más cambios pequeños, mientras que los más experimentados tocan partes profundas o áreas complejas del código, lo que puede alargar los tiempos de build.
Así que el análisis en sí está muy bueno, pero considerando los sesgos inherentes a la muestra, creo que antes de construir una arquitectura para recopilar datos de toda la empresa, lo correcto habría sido empezar con un método simple: hacer benchmarks de los commits recientes en cada laptop.
La razón para reunir estos datos no fue solo comparar entre equipos, sino también acumular datos históricos sobre los tiempos de build de los desarrolladores y medir continuamente el rendimiento de los builds para detectar regresiones.
Cuando vemos que los tiempos de build aumentan, ajustamos con frecuencia la estructura de la base de código para hacer que los builds sean más rápidos.
Un M3 puede compilar 30% más rápido que un M1, pero los builds en red son 15 veces más rápidos. Se podría evaluar si, en vez de darles M3 a los desarrolladores, convenía invertir en builds en red.
Se aplicó una prueba t a datos que no fueron muestreados de forma independiente: varios puntos de datos provenían de personas distintas y, como cada persona realiza tareas diferentes, los requisitos de cómputo pueden variar, generando factores de confusión. Esto viola los supuestos básicos de la prueba t, pero el intérprete de código no lo señaló.
En su lugar, se podría haber usado un modelo lineal mixto de efectos incorporando factores como el dueño de la laptop o la antigüedad como efectos aleatorios.
Aun así, los datos en sí son interesantes, y la parte de la RAM fue especialmente divertida. La caché es poderosa, y tener más RAM ofrece beneficios mayores de lo que mucha gente cree. En general, en una MacBook con más RAM de la necesaria, la mayor parte de la RAM sobrante termina llena de caché.
Si se recopila durante una semana aproximadamente, se puede obtener una muestra de la carga de trabajo real, repetir esos builds en cada categoría de hardware y reutilizarlos más adelante con hardware nuevo.
Como científico, me resulta interesante cómo los programadores manejan los datos.
Hicieron gráficos bonitos, automatizaron muy rápido el análisis con ChatGPT y ChatGPT produjo una prueba t bastante plausible.
Pero había variación según la memoria y el tipo de chip, y aun así no consideraron una regresión lineal; además, hicieron histogramas difíciles de comparar. Podrían haberlos complementado con promedios simples y barras de error, o usar funciones de distribución acumulada (CDF), que facilitan ver solapamientos o desplazamientos.
En general se manejan los datos de la forma en que los muestran las herramientas, lo cual está bastante relacionado con el análisis, el análisis de rendimiento y las suites de software de observabilidad.
Esperar que un ingeniero de software promedio conozca las CDF es parecido a esperar que conozca cuaterniones de gráficos 3D o los fundamentos de escribir shaders.
O también se podría usar regresión cuantílica. Si la hipótesis es M3 > M2 > M1, la conocida prueba de Jonckheere–Terpstra para medianas ordenadas habría encajado muy bien para este tipo de pseudoanálisis.
Para un ejemplo, vean el último gráfico de esta página: https://ggplot2.tidyverse.org/reference/stat_ecdf.html
Es un análisis sólido, pero por experiencia personal quiero dejar una advertencia
En una empresa de software mediana, de unos 2 mil empleados, intentamos mejorar la productividad de desarrollo y exploramos mover el stack de desarrollo a instancias de AWS en vez de comprar laptops nuevas
Al final se convirtió en un proyecto de varios años con unos 4 desarrolladores dedicados full-time y, viendo hacia atrás, no valió la pena en relación costo-beneficio. Reproducir en la nube una experiencia de desarrollo completamente local todavía es demasiado difícil
Así que creo que es mejor actualizar las laptops
El código está en la laptop, pero se sincroniza en tiempo real con servicios remotos sin builds de Docker ni despliegues de K8s, así que realmente se siente local
Sobre todo, permite ejecutar de inmediato pruebas de integración o superiores mientras estás programando, evitando el ciclo commit-push-pray
Para eso usamos Garden(https://docs.garden.io). Usen Garden o no, con las herramientas adecuadas aprovechar la potencia de la nube en el loop interno de desarrollo puede ser bastante excelente
Un artículo con más sobre la experiencia: https://thenewstack.io/one-year-of-remote-kubernetes-develop...
También se volvieron posibles varias cosas que no lo eran en una versión solo local. Por ejemplo, al alternar entre varias ramas, cambiar de máquina en vez de cambiar los archivos locales reduce mucho la latencia del cambio de contexto
Cuando para hacer algo tienes que levantar más de 200 piezas, también se vuelve difícil trabajar en una sola parte que interactúa solo con algunas de ellas
En una era en la que hay servidores de 128+ núcleos y 256+ hilos, cada vez me inclino más a pensar que para la mayoría del software vuelve a ser mejor un monolito
Es puro desperdicio de dinero y tiempo. Uno se da cuenta de que enganchar todas las llamadas al sistema con software basura de proveedores es malo para una toolchain estilo Unix que ejecuta muchísimos subprocesos
En grandes empresas tecnológicas como Google y Meta, el entorno de desarrollo está en la nube para la mayoría de los ingenieros de software
Es una experiencia de desarrollo mucho mejor que la local
Para desarrollo iOS, considerando también los costos, esta fue la conclusión a la que llegué en mi investigación personal
El M2 Pro es bueno, pero la mejora frente al M1 Pro de 10 núcleos no es enorme. En XcodeBenchmark son 136 s contra 120 s: https://github.com/devMEremenko/XcodeBenchmark
El M3 Pro se siente recortado para diferenciarlo del M3 Max y, como solo tiene 6 núcleos de rendimiento, en la práctica es parecido al M2 Pro
Al final compré un M1 Pro de 10 núcleos con poco uso y estoy muy satisfecho. Obtuve el 85% del rendimiento por menos de la mitad del precio de un M3 Pro básico, y también tomé en cuenta que, por lo general, la CPU tiene que ser al menos 33–50% más rápida para que se note la diferencia
Es mucho más eficiente que el M2 Pro y rinde un poco más. En una laptop eso es lo que quiero, y la ancho de banda de memoria no es algo que vaya a usar especialmente
No vi una diferencia tan grande como la que se muestra en este artículo. Puede depender del lenguaje o del proyecto, pero al hacer benchmarks lado a lado con el mismo comando de compilación, no vi diferencias así de grandes
No sorprende, porque la toolchain de compilación es distinta; también en la toolchain de Go se puede ver cómo ciertas especificaciones influyen de forma diferente en cada etapa del build, por ejemplo cuando la memoria adicional ayuda al rendimiento del linker
También vi varias veces la reacción de que el rendimiento del M3 quedó limitado de forma extraña; espero que eso no continúe en los modelos posteriores al M4
120 Hz también estaría bien, pero no creo que llegue a las laptops Air
Fui colaborador principal de Chromium y Node.js, y actualmente soy colaborador principal de gRPC Core/C++, pero los tiempos de compilación nunca me han preocupado demasiado.
Existen las “compilaciones interactivas”, que son compilaciones incrementales para volver a correr las pruebas unitarias relacionadas mientras trabajas, y las compilaciones no interactivas, que dejas corriendo mientras vas por un café o lees el correo. Nunca he visto que un cambio de hardware convierta una compilación no interactiva en una interactiva.
Mi equipo personal es un Intel i7 de más de 5 años con 16 GB de memoria, y al darme cuenta de que necesitaba más memoria para enlazar Node.js en WSL, le agregué otros 16 GB.
Mi laptop de trabajo es una Intel MacBook Pro con Touch Bar, y no creo que tenga un gran impacto en la productividad. Lo importante es el tamaño y la calidad de la pantalla, y la velocidad del almacenamiento. Más que las mejoras de CPU, influye más el sistema de compilación, como la velocidad de las compilaciones incrementales y el soporte para compilación distribuida. En proyectos personales uso Bazel.
La compilación y el enlace deberían terminar prácticamente al instante, tan rápido que ni siquiera se sienta que existe una etapa de compilación.
Está bien que una build de release con técnicas como optimización de todo el programa tarde mucho, pero el ciclo normal de compilar/depurar/probar podría ser instantáneo. La compilación de lenguajes de sistemas es increíblemente lenta por razones heredadas, pero no tiene por qué ser así.
Como terminaba dedicando mucho tiempo a tocar archivos BUILD, empecé a preguntarme si realmente aportaba más valor que un Makefile común. Eso fue hace 3 años, así que quizá el ecosistema público haya mejorado.
No estoy seguro de la velocidad de almacenamiento, y nuestras builds corren todas en máquinas remotas de desarrollo más potentes.
Para quienes quieren hacer análisis de datos con IA como en el artículo, creo que es mucho más fácil cargar los datos en R, Stata u otra herramienta y consultarlos directamente.
Los comandos son más cortos y precisos, y sobre todo la reproducibilidad es mayor.
Lo más difícil en el análisis de datos es entender los datos y el mecanismo que los generó. Para eso se necesita un modelo causal del dominio del problema.
No sé si la IA puede crear un modelo causal útil si antes no fue entrenada con otros datos de ese dominio. Sin ese modelo es imposible interpretar razonablemente los datos, y también me pregunto si los modelos actuales de IA pueden detectar confusión, influencia excesiva de valores atípicos y variables moderadoras de efecto interesantes.
Cuando lo hice, fue con Python y pandas, y se le puede pedir que muestre el código usado para el análisis.
La diferencia es entre cargar los datos en R/Python y buscar “cómo hago xyzzzy” para escribir el código tú mismo, o usar ChatGPT.
La parte de “todos los desarrolladores ejecutan localmente en su laptop un entorno completo de incident.io y obtienen un ciclo de feedback de menos de 30 segundos desde el cambio de código hasta la ejecución” me parece el mayor logro.
Salvo por algunas veces que ayudé brevemente a startups, nunca estuve en una empresa donde se pudiera ejecutar la instancia de desarrollo/local de toda la compañía en una sola máquina.
Siempre hay algo inaccesible y siempre hay trampas.
No entiendo por qué la gente no se enoja más por esta pésima experiencia de desarrollo. Parece que los recién salidos de la universidad hoy no saben lo que se están perdiendo.
Quien no vivió en ese mundo no entiende cuánto mejor es, y lo racionaliza de mil maneras.
Eso sí, el año pasado agregamos Snowflake, y aunque resuelve un problema real, desarrollar iterativamente esa parte es doloroso.
Es lineal respecto a la cantidad de servicios que hay que soportar, y también lineal respecto a la cantidad de ingenieros que hay que soportar. Además aparecen casos de uso variados que no encajan bien, de pronto el equipo de infraestructura se vuelve el cuello de botella para lanzar funcionalidades y la gente empieza a usar enfoques distintos.
Una vez que se abre esa caja de Pandora, es prácticamente imposible volver atrás. Aun así, reducir el ciclo de desarrollo de horas o días a minutos es mucho más importante que reducir esos minutos en un 25%.
Hasta ahora va bien.
Como autor del artículo, gracias por compartirlo.
Incluye varias cosas: perfilado de compilación en Go, creación de un hot reloader y análisis de datasets de builds con IA.
En conclusión, valió la pena actualizar de M1 a M3 Pro, y en las pruebas el Max no marcó una gran diferencia. El M2 está bastante cerca del M3, así que para nosotros no valía la pena actualizar.
Si tienen preguntas, puedo responderlas.
También me interesa cómo afecta ese costo al periodo de recuperación.
O quizá el trabajo terminaba demasiado rápido como para que hubiera una diferencia en el uso real.
La idea es interesante, pero la calidad del análisis de datos parece bastante baja y no estoy seguro de que realmente esté aprendiendo lo que cree que está aprendiendo.
En particular, cuesta entender por qué las compilaciones de menos de 20 segundos aumentan de forma tan drástica al pasar de un M1 Pro a un M2 Pro. En tareas de compilación de código, la diferencia real de rendimiento entre ambos es de alrededor de 20-25%.
Tampoco tiene mucho sentido que las máquinas M3 tengan menos compilaciones de menos de 20 segundos que las M2, o que un M3 Pro con la mitad de núcleos tenga más compilaciones de menos de 20 segundos que un M3 Max.
Es muy probable que las diferencias en el comportamiento de los desarrolladores, como que las personas con distintos tipos de laptop suelan hacer trabajos diferentes, hayan producido estas diferencias.
Algunas observaciones tras una lectura rápida: el compilador de Go parece no aprovechar demasiado los núcleos adicionales, la forma de combinar los datos es fundamentalmente incómoda, y el método de comparación también carece de consistencia porque mezcla histogramas con gráficos de densidad por intervalos y usa rangos distintos en el eje Y.
La Mac no reduce el rendimiento de la CPU por estar usando batería. Si de verdad las compilaciones son más lentas con batería, aunque es difícil afirmarlo solo con el gráfico, probablemente sea porque está activada la configuración de “bajo consumo”.
Un poco tangencial, pero me pregunto cómo otras empresas equilibran la administración de endpoints y el software de seguridad con la productividad de los desarrolladores.
En nuestra empresa corren más de 5 servicios en segundo plano en las laptops de desarrolladores, tanto en Mac como en Windows. Incluyen administración de endpoints, interceptación de elevación de privilegios, interceptación e inspección TLS, antimalware y un cliente VPN.
Esta combinación tiene un gran impacto en el rendimiento. Hagas lo que hagas en la máquina, estos servicios consumen CPU y rendimiento de E/S, y los desarrolladores se han quejado de bloqueos y tirones aleatorios.
Entiendo que la seguridad es necesaria considerando el aumento del ransomware y el robo de propiedad intelectual, pero me pregunto si hay empresas que hayan encontrado mejores formas de ofrecer seguridad con menor impacto en la productividad de los desarrolladores.