¿Es el rendimiento más lento de los lenguajes de programación, realmente, algo malo? [cerrado]

Así es como lo veo.

Hay código de máquina y es todo lo que las computadoras necesitan para ejecutar algo. Las computadoras no se preocupan por los lenguajes de programación. No les importa si el código de la máquina proviene de Perl, Python o PHP. Los lenguajes de programación no sirven a las computadoras. Sirven a programadores.

Algunos lenguajes de programación se ejecutan más lentamente que otros, pero eso no es necesariamente porque hay algo mal con ellos. En muchos casos, es porque hacen más cosas que los programadores de lo contrario tendrían que hacer (es decir, gestión de memoria) y al hacer estas cosas, son mejores en lo que se supone que deben hacer: servir a los programadores.

Entonces, ¿el rendimiento más lento de los lenguajes de programación es realmente malo?

No creo que sea automáticamente malo. Python es más lento que C ++, pero cuando ambos son lo suficientemente rápidos , Python puede ser la mejor opción para el problema en cuestión, incluso si es más lento .

Siempre es una compensación. Para pequeñas tareas puntuales, es mucho más rápido escribir un script Python que una aplicación C ++ que hace lo mismo (el ejemplo típico para mí sería algún tipo de procesamiento de texto por lotes o recorrer un árbol de directorios y hacer algo a los archivos), y realmente no me importa si toma 10 ms o 1000 ms, aunque sea 100 veces más lento, porque me puede tomar la mitad del tiempo escribir y probar.

Por supuesto, sería bueno si Python fuera tan rápido como C ++, por lo que en ese sentido estoy de acuerdo con su afirmación de que "lento = malo". Pero entonces prefiero tener un lenguaje poderoso que se ejecute tan rápido como quiera al no hacer algunas cosas (por ejemplo, verificar los límites de la matriz en matrices sin procesar) siempre que me permita decidir cuándo hacer esa compensación (por ejemplo, usando std: :vector).

Bastante simple: ser lento es algo malo

cuando el programa requiere un cierto nivel de rendimiento

porque sin ese rendimiento no estás cumpliendo los requisitos.

Esto podría ser cualquier cosa, desde una aplicación comercial que necesita procesar consultas en un período de tiempo aceptable hasta un juego que necesita mostrar mucha información en la pantalla en cualquier momento. Si el programa no es lo suficientemente rápido, entonces simplemente no funciona .

Míralo de esta manera: las computadoras son estúpidas . Siguen las instrucciones que cualquier imbécil con una tabla trigonométrica podría seguir. Insisten obstinadamente en hacer lo que dijiste en lugar de lo que querías decir. Ni una pizca de autodirección o intuición. Es horrible.

Lo ÚNICO que tiene una computadora es que es rápido. ¡De Verdad! Un cabeza hueca con un archivador podría hacer el mismo trabajo que una base de datos. Un tipo que hace funcionar una imprenta podría hacer lo que hace Apache. ¡Seriamente! Y lo hicieron, durante cientos y cientos de años, de hecho. Por qué una computadora es buena para CUALQUIER COSA es su velocidad.

Entonces, un lenguaje de programación que (en comparación con otros lenguajes) no puede explotar le falta la ÚNICA ventaja de usar computadoras.

Un lenguaje de programación puede ser de muy alto nivel, "hacer mucho", aún así ser muy rápido. OCaml es un lenguaje de nivel superior que PHP, pero produce un código casi tan rápido como C. Javascript es tan dinámico como PHP, pero puede ejecutarse realmente rápido. Por lo tanto, es principalmente un problema con una implementación de lenguaje, no un diseño. Los lenguajes dinámicos son más difíciles de implementar de manera eficiente, pero no imposible.

La velocidad se puede medir en términos de tiempo de ejecución, tiempo de desarrollo inicial y tiempo de mantenimiento (tiempo necesario para resolver problemas / errores y producir nuevo código y desplegarlo).

Los lenguajes de secuencias de comandos generalmente tienen un tiempo de ejecución más lento pero un tiempo de mantenimiento más rápido porque a menudo puede hacer un cambio rápido e implementarlo sin tener que reconstruir un sistema completo y, a veces, sin siquiera tener que detenerse y reiniciarse.

Por lo tanto, mucho es un equilibrio dependiendo de la velocidad que requiera.

El contexto también es importante. Cargar su configuración inicial que toma 0.5 segundos en lugar de 0.1 segundos no es gran cosa, pero en tiempo de ejecución, tomar 0.5 segundos para realizar una consulta en lugar de 0.1 segundos podría ser un gran problema si tiene que manejar 100 consultas, por lo tanto, tomar 50 segundos en lugar de 10)

Simple: a los clientes les encanta el software rápido. De hecho, todo el propósito de las computadoras es calcular rápidamente.

Lento es relativo. Si tengo el requisito de leer un puerto 10 veces por segundo, un lenguaje que no puede crear un binario que pueda hacerlo es demasiado lento. Si otoh estoy escribiendo una aplicación web donde la secuencia de solicitud / respuesta entre el servidor y el navegador / cliente se mide en segundos y es probable que el usuario pase minutos en una pantalla antes de hacer clic en un botón, un lenguaje de programación que puede manejar el procesamiento de la solicitud en 1 segundo es probablemente lo suficientemente rápido (la mayoría, por supuesto, es mucho más rápido).

Por supuesto, el lenguaje de programación puede ser un factor para determinar la velocidad de ejecución, pero ese no será el lenguaje en sí, sino los compiladores y / o tiempos de ejecución que vienen con él. Esto está claro al ver el desarrollo de Java, donde el rendimiento de las JVM (incluso en entornos de hardware idénticos) a lo largo de los años ha aumentado radicalmente. Y, por supuesto, siempre es posible escribir código terriblemente lento en el entorno que elija. Como afirmaciones como "C ++ es diez veces más rápido que Java" son automáticamente falsas a menos que se califiquen y cuantifiquen exactamente qué condiciones se probaron y cómo. Es igualmente posible crear una prueba donde Java es más rápido que C ++, todo depende de lo que esté usando como código de prueba y de cómo lo ejecute.

Debido a que los lenguajes de programación no existen para servir a los programadores, existen para crear programas para servir a los usuarios.

Si solo necesita una pequeña herramienta personal para hacer algo una vez, puede ser tan lenta como desee. Pero una vez que comienza a implementar en los usuarios, les importa la velocidad y la escala, especialmente si lo van a usar repetidamente. (Por ejemplo, un instalador puede ser lento; es mejor que el programa que instala no lo sea). Y no es solo el lenguaje; Es el programa en general. Si su programa es lento, a los usuarios no les gustará. Y si tienes competencia, a los usuarios que no les gusta tu programa es algo muy malo. Por lo tanto, un lenguaje que contribuya a que a los usuarios no les guste su programa (al hacerlo más lento) es malo.

Soy parte de un equipo que escribe software de control para medios de difusión. Hay una buena probabilidad de que su estación de televisión o radio favorita esté funcionando si está en los EE. UU. El rendimiento es una de las cosas que más escuchamos de los clientes. Originalmente se escribió para pequeñas operaciones de estación única, pero ahora estamos firmando las principales redes de transmisión y cable con cientos de canales, y la escala comienza a convertirse en un problema. Si no podemos hacer que las cosas funcionen rápido para ellos, llevarán sus contratos multimillonarios a las personas que puedan hacerlo, y terminaremos sin trabajo. Es por eso que usamos un lenguaje rápido y compilado y optimizamos la extracción de nuestras bases de datos.

Porque más rápido es mejor. El tiempo es dinero. Si escribe software de servidor y utiliza un lenguaje de programación más lento, compra más servidores. Si escribe un software reducido, pierde clientes frente a sus rivales que son más rápidos.

Para cualquier tipo de software duradero que utilicen las personas, generalmente lo queremos lo más rápido posible. A nivel de la Asamblea, el tiempo de comercialización aumenta demasiado y no es rentable. Todo son compensaciones. Desde una perspectiva comercial, podría ser más rentable dejar que los programadores pobres depuren errores de memoria en C ++, haciéndolo durante varios meses más, si eso significa que el producto es más rápido que sus rivales.

Entonces, la velocidad es realmente importante en muchos programas. Los lenguajes lentos se consideran "malos" hoy en día porque son realmente demasiado lentos (Python puede ser fácilmente 50x - 100x más lento, y eso es demasiado)

Existen lenguajes de programación para servir a los programadores.

No sé cómo llegaste a esta conclusión. Yo diría: los ingenieros de software usan lenguajes de programación para sus necesidades.

Algunos lenguajes de programación son más lentos que otros, pero eso no se debe a que haya algo mal con ellos.

Esta es también una declaración clave. Defina lo que quiere decir usando la palabra "más lento" aquí. Más lento podría significar:

1. Los programas finales, que logran lo mismo, se ejecutan "más lentamente" en un idioma en comparación con otro.
2. El tiempo necesario para crear el programa final puede ser más largo (por lo tanto, algunos lo describirían como "más lento").

Estos dos problemas que vienen a la mente también se entrelazan cuando hay algún tipo de compensación entre el tiempo dedicado al desarrollo y el rendimiento.

Como cualquier software, ser lento puede ser un signo de problemas subyacentes / mal diseño. El diseño es un poco un zeitgeist, sin duda, pero esto no resta valor al hecho de que los principios de diseño en los que se basa ahora están desactualizados y se consideran "malos".

Tome ASP clásico y ASP.net por ejemplo.

Alguien comentó que "a los clientes les encanta el software que cumple con los requisitos y dentro del presupuesto". Bueno, esto es cierto, pero tiene una gran influencia en el software lento, y eso, casi por definición, significa lenguajes de programación (y marcos), algoritmos y configuración más lentos. Un lenguaje de programación lento es posiblemente la parte más importante de todo lo anterior simplemente porque es una base desde la cual le resultará más difícil cambiar. Si usa un Oracle DB y necesita más rendimiento, puede optimizar las tablas / index / etc. Fácil. Si tiene un algoritmo deficiente en su código, puede escribir un código diferente. Si su marco es lento, puede reemplazarlo; eso no es tan fácil pero es factible sin volver a escribir todo. Si su idioma es demasiado lento, prácticamente debe comenzar de nuevo.

Vea en Facebook la molestia que tuvieron para hacer que PHP funcione lo suficientemente rápido cuando necesitaban escalar.

Para el resto de nosotros, los "requisitos de rendimiento no funcionales" a menudo se escriben en especificaciones, especialmente para aplicaciones web escalables. El incumplimiento de la página debe mostrarse al usuario dentro de los 2 segundos posteriores a la solicitud "y usted pierde el contrato (o paga multas). Entonces, sí, a los clientes les encanta el software que cumple con los requisitos, y esos requisitos dirán que tiene que ser rápido (es posible que no le importe cuánto tiempo pasan los usuarios mirando el reloj de arena, pero el cliente sí lo hace, es un costo enorme).

Por ejemplo, en un gran centro de atención telefónica me dijeron que habían determinado que por cada segundo que podía ahorrar en el proceso de recepción de llamadas, se podía "reducir el tamaño" de 1 receptor de llamadas. Eso es dinero real de repente, y un gran incentivo para que los jefes obtengan un software más rápido, eficiente y más utilizable.

Se pasa mucho tiempo preocupándose por los programadores que producen el código lo más rápido posible (y luego prueban y refactorizan la unidad todo el tiempo, jajaja). He descubierto que este no es un factor tan importante como la gente piensa que es: si eres un experto en tu idioma, puedes codificarlo mucho más rápido que si no tienes experiencia. Por lo tanto, un desarrollador experto de C ++ puede escribir código más rápido y con mayor precisión que un desarrollador PHP novato. Así que creo que convertirse en un experto es más importante que elegir un lenguaje 'fácil' y es por eso que no me gusta el culto de 'reescribir en las cosas nuevas y geniales' que parece estar en todas partes hoy en día.

Señalaré que la mayoría de los problemas de rendimiento existen porque el programador hizo un mal trabajo, no porque el lenguaje fuera demasiado lento. Realmente, hay muchas más cosas pertinentes de las que preocuparse en el rendimiento que el idioma que elija. Eso sería aproximadamente el número 1,203,407 en mi lista.

Entonces, ¿el rendimiento más lento de los lenguajes de programación es realmente malo?

Todo lo demás es igual, ir más rápido es algo bueno. Después de todo, nadie realmente quiere esperar más para obtener algunos resultados, y una vez que ese resultado se hace, puede liberar recursos para otras cosas.

Pero no todo lo demás es igual. Para empezar, también es importante producir el resultado correcto , o al menos lo suficientemente adecuado. (Si se permiten resultados completamente incorrectos, puede producirlos muy rápidamente y serán de un valor exactamente cero para cualquiera). Si un cambio a un lenguaje algo más lento hace que sea más probable que se produzca el resultado correcto, generalmente es un Gran compensación. Los lenguajes de nivel superior tienen una ventaja sobre los de nivel inferior, ya que su conjunto más rico de modelos generalmente hace que sea más fácil expresar un problema complejo sin demasiados detalles explícitamente abrumadores.

Por lo general, también es importante administrar el costo de producir el software en primer lugar, agregar nuevas funciones según se desee y mantenerlo funcionando a medida que cambian los sistemas subyacentes. Los lenguajes de nivel superior generalmente permiten un cambio de programación más rápido, y hay mucho valor en mantener los costos de programación dentro del presupuesto. De hecho, mantener los costos bajos permite lograr más cosas diferentes en general, lo que generalmente es algo bueno.

El último punto clave a tener en cuenta es que no es necesario usar solo un idioma , y que muchos sistemas de software tienen la mayoría de sus componentes que no son críticos para el rendimiento. Usar un lenguaje de bajo nivel para producir componentes de alto rendimiento para los bits críticos es sensato, mientras que dejar las partes menos críticas a un lenguaje de alto nivel (para minimizar el costo de producirlos) es sumamente sensato. Además, las características que hacen un buen lenguaje de bajo nivel (la capacidad de controlar con precisión lo que hace la máquina) no son las características que hacen un buen lenguaje de alto nivel (la capacidad de inferir los detalles de descripciones mucho más pequeñas): son diametralmente opuestos, por lo que poder juntarlos y usarlos para sus fortalezas y evitar sus debilidades, eso es realmente una gran cosa.

¿Qué componentes deben recibir el tratamiento de alto rendimiento? La optimización? Medir ellos. Perfilarlos . Encuentra la verdad en lugar de adivinar. Concentra tu esfuerzo donde sea más beneficioso.