Creo que esta captura de pantalla de una medición de productividad realmente existente es suficiente para transmitir el significado del artículo, pero si el lector está interesado en mis pensamientos sobre este tema, entonces bienvenido.
Los programadores están obsesionados con la velocidad de ejecución del programa. Monitoreamos la velocidad incluso cuando esta velocidad no es muy importante. A veces contrario al sentido común y la lógica. Ni siquiera comprende completamente lo que las palabras "velocidad" o "rendimiento" realmente significan en cada caso. Todavía queremos el hardware más rápido, el lenguaje más rápido y el marco más ligero.
De buena gana creo que usted, nombre de usuario, no es así. Que usted mismo puede escribir el punto de referencia correcto, sabe cómo funciona este o aquel tiempo de ejecución, odia la optimización de la velocidad solo por la optimización de la velocidad y sabe mucho sobre hardware. Pero hay más personas del párrafo anterior. Comprobado
Al ver el ejemplo en la imagen de arriba, primero me atraganté con café ...
- ¿Cómo puede el mecanografiado funcionar más rápido que JavaScript y al mismo tiempo consumir varias veces menos memoria?
- De ninguna manera!
El mecanografiado no tiene su propio tiempo de ejecución. Es decir, no puede ejecutar el mecanografiado en ningún lugar o casi en cualquier lugar. Primero debe compilarlo en JavaScript, que luego se ejecuta en tiempo de ejecución, que este mismo JavaScript entiende. En este caso, el nodo v11.3434 actuó como tal tiempo de ejecución. Por una feliz coincidencia, el ejemplo de JavaScript también se ejecuta en el mismo tiempo de ejecución.
En lugar de comparar idiomas, tenemos una micro competencia en programación deportiva.
→ código mecanografiado
→ código javascript
Resulta que el tiempo de ejecución, el consumo de memoria y otras características dependen críticamente de quién escribió este código de verificación y cómo. Por supuesto, aquí puede tomar el argumento de que el mecanografiado lo obliga a escribir "el código correcto". Pero nadie se molesta en compilar el mecanografiado en JavaScript, y tampoco vi lugares con optimizaciones.
Por cierto, ¿cuánto tiempo has visto a alguien escribir un código similar y pasó por una revisión? Sólido, OOP y FP no huelen aquí. El código está escrito explícitamente en un estilo de procedimiento. Porque tiene una tarea diferente. Comprenda correctamente, aunque el código resuelve el problema, requiere una refactorización antes de la producción. Y no se sabe cómo la refactorización afectará el rendimiento. Pero esto es probablemente una trampa.
Descubrimos un ejemplo. Obviamente, el ejemplo es inadecuado.
Pero veamos cómo otros lenguajes de programación pasaron la misma prueba.
¿Qué piensas, qué tan correcto es concluir que Swift es más rápido que Go? Creo que eso está mal. Es suficiente ver que dos implementaciones de Rust (líneas 2 y 6) difieren en el tiempo en 2 veces.
Y aquí el problema ya parece más grave. Si la comparación de mecanografiado y javascript se considera una broma, en el caso de otros idiomas, el problema no es tan obvio. ¿Y comenzarías a entender cuál era el problema si vieras tal informe?
Resulta que el código de referencia debe ser monitoreado de cerca.
Pregunta: ¿Cuándo fue la última vez que vio a una persona que intentaba verificar cómo se escribe el código de referencia justo después de ver gráficos de rendimiento estándar hermosos?
Los encuentro muy raramente. Creo que tales ingenieros son muy pocos.
Por otro lado, ante mis ojos hay muchos ejemplos cuando, en base a tales pruebas, se llega a una conclusión sobre el rendimiento y la ligereza de la tecnología. Y, por cierto, se está formando la opinión pública.
Aquí puede comparar el rendimiento de los principales marcos de javascript.
¿Todavía confías en los resultados? Yo no
Eso es todo. Pero hay buenas noticias. La habilidad del programador sigue siendo una influencia importante en el rendimiento del programa.
Conclusión
Las microbenchmarks no le mostrarán nada a menos que sea profesional en el desempeño de una plataforma en particular. Mejor aún, usted mismo escribe estos puntos de referencia teniendo en cuenta exactamente sus requisitos y condiciones, mientras comprende lo que está haciendo.
PD:
La publicación está escrita como una respuesta a comparaciones apresuradas y conclusiones sobre la productividad futura. Por supuesto, todas las conclusiones y argumentos del artículo se pueden dar sin este ejemplo, pero con números y detalles es más divertido y claro.