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

18

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?

Emanuil Rusev
fuente
22
más lento de qué manera? tiempo de compilación, tiempo de ejecución, tiempo de escritura, alguna otra métrica?
Matt Ellen
1
Solo señalaría que las computadoras rápidas y los compiladores que generan un lenguaje de máquina eficiente, obviamente son buenos, excepto que permiten a los programadores ser más vagos, por mucho. Cuando los productos tienen problemas de rendimiento, a menudo se debe a suponer que ciertas cosas son "rápidas", como la administración de memoria y las notificaciones.
Mike Dunlavey
55
@Mike: Alternativamente, los programas se ejecutan lentamente debido a una actitud que Jeff resumió recientemente en su blog: "Los algoritmos son para personas que no saben cómo comprar RAM". Si el programa se ejecuta en tiempo cúbico en lugar de tiempo O (N log n), la potencia de la computadora realmente no importa para grandes problemas.
David Thornley
2
@David: no podemos obtener más de 512 Gb de RAM en nuestro servidor, por lo que tenemos que escribir mejores algoritmos ahora.
JBRWilkinson
2
Depende de dónde estén los cuellos de botella. Si el programa espera E / S el 99.9% de las veces, no importa si el programa en sí es 10 veces más lento que si está escrito en ensamblador artesanal.

Respuestas:

50

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).

ggambett
fuente
No dije que "lento = malo". Sin embargo, gracias por compartir tus pensamientos.
Emanuil Rusev
99
+1 'lo suficientemente rápido' Lento es malo cuando una implementación es 'demasiado lenta / no lo suficientemente rápida'. En cualquier otro momento no importa.
Kirk Broadhurst
44
+1 'lo suficientemente rápido'. Dependiendo de lo que haga, el tiempo del programador podría valer MUCHO más que los ahorros potenciales en el tiempo de ejecución.
Jonas
3
@Jonas: casi nunca es el caso, es solo que ves el salario del programador; no ves a los usuarios con la cabeza fruncidos mientras la aplicación se arrastra gritando "vamos, qué difícil es eso, un montón de software basura". Si publicaran el TCO de software lento v software rápido, vería que sus prioridades cambian inmediatamente su departamento de ventas.
gbjbaanb
1
@mcmcc: No estaba hablando de idiomas allí, sino de la experiencia del usuario. Cuando haces clic en un botón, algo tiene que suceder de inmediato. Cuando inicia un cálculo, está bien si lleva un tiempo, siempre que haya un indicador de progreso útil.
Jonas
18

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 .

Kirk Broadhurst
fuente
2
..y, a menudo, los requisitos no se escriben en una especie de "más de X segundos para recuperar una página que hace que el usuario promedio del sitio web se mude a otro sitio"
JBRWilkinson
1
@JBRWilkinson sí, o si el sistema es demasiado lento, entonces aparecerán nuevos requisitos de rendimiento;)
Kirk Broadhurst
12

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.

Dan Ray
fuente
13
Te falta un bit importante: las computadoras son estúpidas, rápidas y previsibles , mientras que erratum humanum es. Y en muchos casos esta previsibilidad es mucho más importante que una velocidad absoluta.
SK-logic
55
Cualquier lenguaje de programación explota la velocidad de la computadora. Python en una de las computadoras OLPC originales hace las cosas mucho más rápido de lo que puedo a mano. Tenga en cuenta que mi computadora portátil actual (comprada hace dos años, y no la mejor de la línea en ese momento) es aproximadamente de cien mil a un millón de veces más potente que la primera computadora de mi casa en la mayoría de los casos.
David Thornley
44
Sin mencionar que una computadora consume mucha energía para usar (particularmente servidores), y que hay una preocupación percibida con el consumo de energía (la tecnología verde), y que generalmente un programa más rápido hace más con la misma cantidad de energía que un programa más lento, por lo que cuenta (particularmente en los servidores, que consumen mucho)
Coyote21
44
@ SK-logic La previsibilidad de la computadora es exagerada. Como Joseph Weizenbaum señaló muy bien, los sistemas grandes tienden a complicarse tanto que no son predecibles y nadie puede PREDECIR el resultado de una ejecución determinada. Se convierte en una cuestión de fe o esperanza. No puede probar formalmente que un programa siempre hará lo que pretendía (por lo tanto, no es predecible).
Omar Kohl
2
Sin embargo, si la velocidad (de ejecución) es el objetivo final, ¿por qué no todos escribimos nuestros programas en código máquina?
Emanuil Rusev
5

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.

SK-logic
fuente
¿Crees que los lenguajes que se consideran lentos (en términos de ejecución), como PHP, se pueden implementar para ejecutarse más rápido?
Emanuil Rusev
1
Zend Optimizer alguien?
user281377
Permítanme preguntar esto de otra manera: ¿qué hay en la implementación de PHP que lo hace lento?
Emanuil Rusev
66
Sí, se puede implementar mejor. Requerirá mucho esfuerzo: una interpretación abstracta para especializar tipos dinámicos, por ejemplo, es bastante complicada y aún no está bien investigada. Un lenguaje estático es mucho más fácil de traducir a un código altamente eficiente. Entonces, PHP es lento principalmente porque es dinámico. Y, bueno, originalmente tenía una implementación muy pobre y poco profesional, así como muchos otros lenguajes de script.
SK-logic
El compilador HipHop, iniciado por Facebook, puede traducir PHP en código C ++, por lo que es realmente rápido.
JBRWilkinson
3

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)

CashCow
fuente
100ms es efectivamente instantáneo en la percepción del usuario. 500ms es bastante notable. Si el usuario realiza consultas, esa es una diferencia notable en el flujo de trabajo.
David Thornley
3

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

Nemanja Trifunovic
fuente
11
mal, en realidad. Los clientes adoran el software que cumple con los requisitos y dentro del presupuesto. No podría importarles menos si una pantalla tarda 19 milisegundos en compilarse en lugar de 15, porque nunca se dan cuenta (si tarda 15 segundos en construirse, eso es otra cosa). Tampoco les importa si usa un "lenguaje rápido", solo quieren algo que funcione según las especificaciones y dentro del presupuesto.
Jwenting
44
19 ms frente a 15 ms pueden no marcar la diferencia, pero 500 ms frente a 300 ms definitivamente lo hacen y puede marcar la diferencia entre un producto exitoso y un fracaso.
Nemanja Trifunovic
2
+1 "A los clientes les encanta el software que cumple con los requisitos y dentro del presupuesto". Por otro lado, ciertos usuarios finales, que no pagan directamente por el software, como los empleados de una gran empresa, no se preocupan realmente por los costos de desarrollo. Por supuesto, como proveedor de software, su tarea más importante es mantener felices a esas personas, que realmente le pagan.
Zsolt Török
@Zsolt: Eso realmente depende del tipo de software que esté desarrollando. Por lo general, trabajo en productos donde los usuarios finales pagan los productos directamente o influyen en las decisiones de compra: no nos dan especificaciones y no les importa nuestro presupuesto. Tal vez debería haber usado el término "usuarios", en lugar de "clientes".
Nemanja Trifunovic
44
Hablando como usuario (en lugar de como desarrollador), puedo decir que la capacidad de respuesta general (nota: diferente a la velocidad) es un factor importante en mi decisión de elegir un programa sobre otro. Esta es una razón por la que uso pocas aplicaciones Java, por ejemplo; el tiempo de inicio en JVM solo da como resultado aplicaciones que comienzan con -5000 puntos en esta área;). Sin embargo, en serio, la capacidad de respuesta puede (a menudo lo hace) hacer la diferencia entre que la interfaz de usuario de su producto sea torpe o efectiva, y a veces eso puede ser difícil de lograr si el lenguaje que está utilizando induce tartamudeos o espera de E / S de disco largo.
Billy ONeal
3

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.

jwenting
fuente
3

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.

Mason Wheeler
fuente
3

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)

kizzx2
fuente
2

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.

JK
fuente
3
Tiene razón al decir que "los ingenieros de software usan lenguajes de programación para sus necesidades". Esto solo respalda la afirmación de que "existen lenguajes de programación para servir a los programadores".
Emanuil Rusev
1
Yo diría: los ingenieros de software usan lenguajes de programación para resolver problemas (que generalmente no son propios, sino de sus clientes).
Péter Török
@Emanuil: No diría "un martillo sirve a un manitas / humano", sino que se utiliza un martillo para completar una tarea (por ejemplo, clavar un clavo, golpear a alguien que no te gusta, etc.). @ Péter: Me pregunto cuántas personas simplemente escriben '@Peter'. Pero si puede acuñar el término 'problema' para todo , creo que nuestras declaraciones son efectivamente sinónimos.
JK
1

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.

Tom
fuente
1

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.

gbjbaanb
fuente
1

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.

HLGEM
fuente
0

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.

Compañeros de Donal
fuente