¿Por qué la gente todavía dice que Java es lento? [cerrado]

Durante mucho tiempo en SO y en otros lugares, Java tiene la reputación de ser lento. Desde bromas hasta muchos comentarios en preguntas y respuestas, la gente todavía cree que Java es lento basado únicamente en su experiencia en los años 90.

Este es mi problema: hemos refutado (la mayoría) de las razones por las que la gente cree que Java es lento. Fuera de las cosas pequeñas, Java es bastante rápido.

Entonces, ¿por qué la gente todavía se niega a creer que Java es rápido ahora? ¿Es parte de su mentalidad que algo que no sea C / C ++ es lento? ¿Es porque la gente no controla con el tiempo? ¿Es porque las personas son parciales?

Son las aplicaciones. Como nota, nos hemos demostrado, una y otra vez, que en escenarios artificiales código Java puede cumplir o incluso superar el rendimiento de los llamados lenguajes "performant" como C, C ++, Lisp, Visual Basic 6 o JavaScript. Y cuando se les presente tal evidencia, la mayoría de los oponentes sanos y de mente abierta se quedarán boquiabiertos y prometen nunca más difundir tal calumnia.

... pero luego, encienden Eclipse, o NetBeans, o Guiffy, o habilitan el soporte de Java en su navegador, o intentan ejecutar una aplicación en su teléfono favorito. Y esperan a que responda ...

... y espera ...

... y espera ...



... y espera ...







... y espera ...











... y ...




... ¿qué prometí no volver a hacer nunca más? ? Lo siento, debe haberme quedado dormido ...

Esta pregunta opera en premisas falsas: donde cuenta, Java sigue siendo lento. Donde cuenta son los algoritmos de computación pesada en grandes conjuntos de datos. Por supuesto, estos pueden optimizarse, a veces para estar a la par con el código C / C ++, pero solo a costa de la modularidad y el carácter genérico. El código eficiente de C ++ se puede diseñar para que sea genérico y se pueda usar como una biblioteca de uso general. El código Java no puede. Basta con mirar el Array.sortmétodo altamente optimizado , que utiliza diferentes implementaciones para todos los tipos fundamentales, y cuya variante de objeto sigue siendo mucho más lenta que C ++ 'genérico sortporque estos objetos tienen que despachar dinámicamente las comparaciones de igualdad.

Por supuesto, las optimizaciones justo a tiempo que realiza el motor HotSpot pueden predecir el objetivo de estas llamadas virtuales e intentar la inserción. Pero esto sigue siendo más lento que la llamada directamente en línea que se envía dentro del sortmétodo de C ++ .

Un antiguo colega mío ha realizado comparaciones comparativas de un problema en grandes conjuntos de datos ( conteo de q- gramas usando formas dinámicas) con una implementación de C ++ con plantilla y una implementación de Java orientada a objetos. El código Java fue de órdenes de magnitud más lento que el código C ++.

Por supuesto, esto es comparar manzanas con naranjas. Pero el punto es que la implementación de Java fue la mejor implementación posible (en términos de rendimiento, dado el grado de modularidad requerido para una biblioteca), y también lo fue la implementación de C ++.

Desafortunadamente, los datos de referencia no están disponibles gratuitamente, pero otros han encontrado números similares al comparar la sobrecarga de abstracción de tiempo de ejecución. Por ejemplo, Scott Meyers escribe en Effective STL sobre la sobrecarga de la qsortfunción genérica de C :

El tipo de C ++ prácticamente siempre avergüenza a qsort de C cuando se trata de velocidad. [...] En tiempo de ejecución, sort realiza llamadas en línea a su función de comparación ... mientras qsort llama a su función de comparación a través de un puntero. [...] En mis pruebas en un vector de un millón de dobles, [ordenar] corrió hasta un 670% más rápido ...

Porque es lento ... en algunas aplicaciones. Las aplicaciones de escritorio tienen que responder desde el principio y la sobrecarga de inicio se considera lenta.

Por otro lado, si ejecuta un servidor, no importa si hay algo de calentamiento (análisis y compilación JIT): lo hace una vez en la luna azul, por lo que la mayoría de las veces no puede considerarse completamente lento.

Yo diría que es porque cuando la gente lo encontró por primera vez, fue lento. En base a eso, formaron una impresión de ello. Es improbable que esa impresión cambie si no la usan, y no la usan debido a esa impresión: es un círculo vicioso.

Debo admitir que tuve la impresión de que Java era lento, y sí, eso fue por mi exposición anterior. Ahora he pasado a diferentes idiomas y he tenido una exposición extremadamente limitada a Java desde entonces. En consecuencia, mi opinión no ha cambiado mucho.

Porque lleva una generación cambiar las percepciones de las personas sobre un producto

No tiene nada que ver con qué tan rápido se vuelve Java. En la mente de las personas, Java es un identificador constante asociado con la palabra 'lento'. Hay poco, nada que usted u Oracle puedan hacer al respecto.

Simplemente esté feliz de que Oracle no haya destruido la cultura de programación de Java (todavía) haciendo algo imprudente o estúpido . Como cobrar costos de licencia excesivos para usarlo. O demandar a personas basadas en patentes de software que anteriormente pertenecían a Sun. ::suspiro::

Odio ser el detractor aquí, pero, a menos que Oracle y Google resuelvan la lucha de Java en buenos términos, o Google se vea obligado a comprar Java y lo convierta en una plataforma de código abierto 'adecuada', Java está en camino de ser el niño El patio de recreo que tiene piojos. Es decir, nadie querrá tocarlo con un poste de 20 pies.

Nota: Para ser claros, cuando digo generación, estoy hablando en términos de personas, no en términos de computadora. Es decir, hasta que las personas que sostienen esa percepción mueran de vejez o sean reemplazadas por una generación más joven, la percepción se mantendrá verdadera. Piense en términos de 5 décadas, no de 5 años.

Una razón es que las personas confían en lo que otros dicen en lugar de lo que ven .

Según lo que me dijeron cuando comencé a programar, Java es "más lento" que C ++, y la razón por la que podría usarse Java es porque es "conveniente y más fácil". Se cree muy comúnmente que Java brinda seguridad y conveniencia, a costa del rendimiento. Incluso cuando se inventa C #, la gente cree que es más rápido que Java porque es "nativo".

Pero la verdad que la gente ve sin sentirlo es que, eclipse, el IDE construido con Java, es absolutamente el IDE MÁS RÁPIDO en su clase. He usado casi todos los IDE de flujo principal, los de MS y GNU, Borland ..., el eclipse es el rey absoluto de los IDE, en gran parte debido a que es rápido.

Otra razón es su largo tiempo de arranque .

Java no es adecuado para desarrollar una aplicación pequeña que permanezca en la bandeja del sistema, consuma un poco de memoria, abra un cuadro de diálogo que le recuerde tomar un descanso; o un bloc de notas que usa para abrir un archivo de texto, leerlo y cerrarlo. Debe usarse en algo GRANDE, como un servidor web que siempre está ahí, hacer un uso optimizado de su recurso informático, responder a millones de solicitudes cada hora. O un IDE como eclipse que gestiona miles de archivos de espacio de trabajo. No sabes que tu aplicación Java es rápida hasta que se haya ejecutado durante al menos varias horas, creo.

@bigown "¿Por qué la gente todavía dice que Java es lento?"

Porque son tontos. Porque no tienen experiencia laboral, pero piensan que son la encarnación viva de Dikjstra o la segunda venida de Linus Torvald, oh, no sé. Las razones para decir algo tan retrasado son muchas, pero generalmente la estupidez, el fanboyismo subjetivo y sin sentido, y la atención emocional parecen estar detrás de ellos.

Diseñemos esto para que pueda ver la verdad de lo que acabo de decir arriba:

Primero, qué es lento, en qué contexto, para qué, bajo qué condiciones, con qué propósito de ingeniería / científico / negocio (por decir que apesta no es uno de ellos). Cualquier persona que diga "X es lento" para cualquier tecnología X, o simplemente "X es Y", donde Y es algún tipo de enunciado negativo, sin responder ninguna de las preguntas anteriores debe descartarse como un tonto. Declaraciones como esa no tienen lugar en la ingeniería. En política y en salas de chat juveniles, tal vez, pero no en ingeniería.

En segundo lugar, la mayoría de estos tontos equivocados lloran porque Java es lento porque ZOMG, su eclipse tarda una eternidad en encenderse (caramba, carga la cosa con todos los complementos y adivina qué sucede). La mayoría de estos tontos ni siquiera saben cómo para ajustar jvm para que eclipse funcione rápidamente (o para cualquier aplicación Java para el caso). Es decir, no tienen idea sobre el ajuste del rendimiento, que es una realidad no solo para Java, sino para cualquier sistema no trivial, ya sea hardware o software. Entonces, allí mismo, se desarman por cualquier validez técnica al hacer tales declaraciones sin sentido.

En tercer lugar, consideremos para qué sirve el grueso del desarrollo de Java: OLTP back-end en primer lugar; los sistemas de monitoreo vienen en segundo lugar. Cualquier tipo de sistema está destinado a ejecutarse en clústeres y a ejecutarse sin interrupciones durante semanas, si no meses. ¿Realmente importa entonces que su pequeña aplicación de eclipse o juguete tarde un minuto o dos en cargarse cuando el propósito de las aplicaciones REAL Java es ejecutarse por períodos prolongados? Contexto, personas, contexto.

Por último, la columna vertebral de OLTP en Google y Ebay se ejecuta en Java. Tomaría eso como una prueba por contradicción de que Java no es lento (al menos para las condiciones que importan, no para pequeños experimentos con juguetes, puntos de referencia y evidencia anecdótica no verificable hecha específicamente con el propósito de decir "el X es lento, apesta").

Hay ingeniería, y hay fanboyismo. ¿Adivina a qué categoría pertenecen las declaraciones como esas?

Porque es así, ¿podemos cerrar este tema de una vez y para siempre?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [desplácese hacia abajo a las tablas, Java es 3.7-12.6 veces más lento que C ++, investigación realizada por empleados de Google]

PD: Si no es así, llámame al menos una aplicación Java ágil para empezar, no he visto una antes.

TMHO, esto se debe al tiempo necesario para iniciar la VM en el navegador. Si una aplicación comienza lentamente, la gente solo recordará eso. Porque, el largo tiempo de inicio es realmente molesto. De Verdad. Uno de mis compañeros de trabajo me dijo que no usa Firefox porque es demasiado lento. (?!?) Pero, sí, está bien, en Windows, Firefox tarda mucho tiempo en aparecer. Según él, esta aplicación es lenta, se decidió por la velocidad general de la misma.

¿Lento en comparación con qué? Estoy pensando en cambiar de Ruby ordinario a JRuby (ruby basado en Java) porque he oído que es más rápido.

Las opiniones son opiniones, y los hechos son hechos.

Aquí hay un hecho de Google Code Jam, que posiblemente desafía a los programadores a resolver problemas informáticos difíciles en un corto período de tiempo, lo que significa que el rendimiento del lenguaje que utilizan juega un papel importante:

Durante las últimas ediciones (2009, 2010, 2011), alrededor del 75% de los programadores que llegaron a las rondas finales usaban C ++, en comparación con alrededor del 15% que usaban Java.

Fuente -> http://www.go-hero.net/jam/

Alrededor de 1997 usé un HP Vectra VE (200 MHz) y Windows 95. La mayoría de las aplicaciones se ejecutaron muy rápido en esto, pero luego probé algunas aplicaciones escritas en Java (IDEs, si no recuerdo mal). Eran muy lentos, al menos las partes GUI de ellos. Tardaron mucho tiempo en iniciarse y los elementos de la GUI (p. Ej., Menús) no respondieron muy bien; hubo retrasos en la retroalimentación visual. Además, dado que las aplicaciones de la GUI de Java tenían (tiene) un aspecto bastante distintivo, aprendí a asociar este aspecto (y Java) con un bajo rendimiento.

Depende de lo que quieras decir como lento.

En primer lugar, Java progresó recientemente y es muy rápido en la mayoría de los casos. Pero :

• Java es lento al inicio, porque debe cargar la JVM antes de hacer nada.
• Algunas características de seguridad pueden matar las actuaciones en algunos casos. La verificación encuadernada con acceso aleatorio es un ejemplo.
• Hacer que algo realmente rápido en Java requiera trabajar contra la JVM (para aprovechar la línea de caché por ejemplo).
• La falta de metaprogramación implica una penalidad en el tiempo de ejecución con cada abstracción, por lo que el rendimiento conlleva el costo del diseño en muchos casos.
• Java difícilmente puede garantizar la restricción de tiempo real, por diseño, y esto podría ser considerado como "lento" por algunas personas.

Por cierto, Java es, en algunos casos, más rápido que Vanilla C / C ++. Pero estos idiomas te dan las herramientas para modificarlos.

Java es un lenguaje de programación dirigido a la productividad. Ahora es lo suficientemente rápido para la mayoría de las aplicaciones, pero no lo es para otras.

En general, la lentitud de Java es un argumento sobreutilizado porque es irreverente en la mayoría de los casos.

El código Java canónico simple tiende a estar a la par o más rápido que el código C / C ++ / D canónico simple. El código simple y canónico tiende a realizar muchas asignaciones de memoria innecesariamente, no se ajusta particularmente a ninguna arquitectura de CPU, no tiene toneladas de optimizaciones de bajo nivel, etc. El HotSpot GC de Java es nada menos que sorprendente, y las optimizaciones de VM tienden ser mejor de lo que un compilador estático podría hacer.

Por otro lado, si realmente necesita rendimiento y está dispuesto a ajustar manualmente las cosas para obtenerlo, C / C ++ / D ofrece muchas más oportunidades para esto. No puede usar el ensamblador en línea en Java. No puedes usar trucos de punteo de tipo sucio para tratar los números de coma flotante como conjuntos de bits. No puede usar esquemas de administración de memoria personalizados que pueden ser más rápidos que el GC para su caso de uso específico. No puede asignar casi tanto en la pila en Java como en C / C ++ / D. En Java, la única forma de obtener algo más o menos equivalente a funciones de orden superior es con interfaces y enlaces de tiempo de ejecución. En D y (creo, corríjame si me equivoco) C ++, puede pasar funciones a las plantillas, lo que permite que se produzca el enlace en tiempo de compilación sin pérdida de flexibilidad.

Otro punto para la "lentitud" de Java es el tiempo de ejecución de 64 bits.

He escuchado a algunas personas quejarse de que Java es muy lento para ellos en computadoras de 64 bits. Como resultado, el tiempo de ejecución de Java de 64 bits utiliza el servidor JVM que compila todo el programa antes de comenzar.

AQUÍ hay una explicación de por qué la máquina virtual de 64 bits comienza más lentamente.

Por ejemplo en Windows:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

El rendimiento de Java es muy subjetivo, sin embargo, la percepción de por qué Java es lento es en gran parte por razones que otros han notado: la percepción de la gente de algo está coloreada por su experiencia anterior con él y Java no siempre ha sido un lenguaje bien optimizado. la capucha. Del mismo modo, Eclipse de vainilla no es exactamente un IDE rápido para trabajar y palidece en términos de capacidad de respuesta en comparación con un IDE como Visual Studio.

Sin embargo, dicho esto, fuera de los problemas de UI que Java tiene al inicio, es lo suficientemente rápido para la mayoría de las aplicaciones. Si busca, puede encontrar artículos que lo comparan con otros idiomas y la mayoría de los resultados presentados lo colocan en el rango donde solo será un problema cuando se trata de conjuntos de datos importantes.

En el campo de la bioinformática se usa bastante porque está bien soportado y ya hay una base de instalación para, una de las ventajas que tiene Java es que puedes hacer un desarrollo bastante rápido con él que no puedes hacer con C Si observa los lenguajes utilizados para la bioinformática (yo uso R, Python y Java regularmente) notará que ninguno de ellos es exactamente el más rápido y no es inusual que los conjuntos de datos en bioinformática se encuentren en los años 100. de gigabytes de información. Al final del día, el tiempo humano es aún más valioso y, aunque las diferencias de velocidad son notables, el tamaño de los conjuntos de datos tiende a ser lo suficientemente grande como para funcionar de la noche a la mañana.

Si fuera más fácil escribir una interfaz de usuario rápida en Java, es bastante probable que la percepción de la velocidad se salga del radar, ya que la mayoría de las personas no presionan los idiomas lo suficiente como para que la velocidad sea realmente un problema a diario.

Para lanzar una moneda sin valor, encuentro que las aplicaciones web de Java generalmente tienen tiempos de inicio y respuesta largos, donde me parece que Python o Ruby lo habrían hecho mejor.

Utilizo Eclipse para la mayor parte de mi programación, y debo decir que Java es tan rápido como cualquier otra cosa, si no más rápido ejecutándose localmente y "independiente".

Diría que Java es infinitamente lento, no solo lento, porque no resuelve problemas simples que son fáciles en lenguajes reales de alto nivel.

Déjame darte un ejemplo simple. Hay una optimización simple que se aplica al mapear una lista dos veces, llamada deforestación: aquí está la regla escrita en mi idioma Felix:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

que dice: en lugar de mapear la lista x con f, luego mapearla nuevamente con g, que requiere dos recorridos de la lista y hacer una lista temporal de basura, simplemente mapee la lista con la composición de las funciones.

Esta es una optimización de alto nivel mucho más significativa que el rendimiento de bajo nivel de Java JVM. La especificación que proporcioné anteriormente no es solo una sintaxis bonita, esta es una instrucción escrita por el usuario que le dice al compilador de Felix cómo realizar una optimización.

Por favor, muéstrame cómo hacer este tipo de cosas en Java. ¿No? Entonces Java es lento. Muy lento. [Haskell puede hacer esto automáticamente, creo].

Y antes de decir "pero Java es un lenguaje OO, este tipo de optimización no se aplica" ... bueno, ese es exactamente mi punto. Java apesta, y ser OO es una de las principales razones.

La optimización de JIT nunca puede acercarse a competir con los tipos de optimizaciones que puede hacer un compilador decente.