tuning - ¿Java es realmente lento?

java profiler (19)

Java tiene cierto grado de reputación por ser lento .

¿Java es realmente lento?
¿Si es así por qué? ¿Dónde está (o estaba) el cuello de botella? ¿Es debido a JVMs ineficientes? ¿Recolección de basura? ¿Bibliotecas de bytecode puras en lugar de código C envuelto en JNI? Muchos otros idiomas tienen estas características, pero no tienen esta reputación de lentitud.

A mediados de los años noventa, cuando Java llegó a la corriente principal, C ++ era el idioma dominante, y la web todavía era bastante nueva. Además, JVMs y GC fueron conceptos relativamente nuevos en el desarrollo de la corriente principal. Las primeras JVMs fueron algo lentas (en comparación con C ++ que se ejecuta en metal desnudo) y también sufrieron a veces largas pausas de recolección de basura, lo que llevó a una reputación de que Java era lento.

Como dice Pascal, Java está a la par de otros lenguajes de alto nivel. Sin embargo, como alguien que trabajó con las JVM originales en Windows 98 , en ese momento el nivel de abstracción proporcionado por la máquina virtual Java era, digamos, doloroso.

Básicamente, fue la emulación de software con poca o ninguna optimización que damos por sentado hoy en la JVM.

Creo que algún día, quizás en un futuro no muy lejano, los lenguajes compilados JIT superan a los compilados en cualquier aspecto (bueno, tal vez no el tiempo de inicio / consumo de memoria) debido a que los compiladores JIT pueden hacer un uso intensivo del tiempo de ejecución comportamiento y la plataforma en la que se ejecutan.

Después de leer una página llena de comentarios que dicen que Java no es lento, solo tengo que responder con una opinión diferente.

La lentitud de un idioma depende mucho de sus expectativas para "rápido". Si considera que C # es rápido, Java también es rápido. Si el dominio de su problema está relacionado con las bases de datos o con el procesamiento semi-en tiempo real, Java también es lo suficientemente rápido. Si le agrada escalar su aplicación agregando más hardware, es probable que Java sea rápido para usted. Si considera que una velocidad de factor constante en la escala de 5-10 no lo justifica, probablemente considere que Java es rápido.

Si realiza cálculos numéricos en grandes conjuntos de datos, o está vinculado a un entorno de ejecución, donde los recursos de la CPU son limitados, donde una aceleración constante en la escala de 5-10 sería enorme. Incluso una aceleración de 0.5 puede significar una reducción de 500 horas para que el cálculo se complete. En estos casos, Java simplemente no le permite obtener ese último tramo de rendimiento, y es probable que considere que Java es lento.

El principal culpable en el "largo tiempo de inicio" es la vinculación dinámica. Una aplicación Java consiste en clases compiladas. Cada clase hace referencia a otras clases (para tipos de argumentos, invocaciones de métodos ...) por nombre . La JVM debe examinar y hacer coincidir esos nombres al inicio. Lo hace de forma incremental, haciendo solo las partes que necesita en un momento dado, pero eso todavía es algo que debe hacer.

En una aplicación C, esa fase de enlace se produce al final de la compilación. Es lento, especialmente para grandes aplicaciones, pero solo el desarrollador lo ve. La vinculación produce un archivo ejecutable que el sistema operativo simplemente tiene que cargar en la memoria RAM "tal cual".

En Java, la vinculación ocurre cada vez que se ejecuta la aplicación. De ahí el largo tiempo de inicio.

Se han aplicado varias optimizaciones, incluidas las técnicas de almacenamiento en caché, y las computadoras se vuelven más rápidas (y se vuelven "más rápidas" que las aplicaciones "más grandes"), por lo que la importancia del problema se ha reducido últimamente; pero el viejo prejuicio permanece.

En cuanto al rendimiento posterior, mis propios puntos de referencia en cálculos compactos con acceso a conjuntos (principalmente funciones hash y otros algoritmos criptográficos) generalmente muestran que el código C optimizado es aproximadamente 3 veces más rápido que el código Java; a veces C es solo un 30% más rápido que Java, a veces C puede ser 4 veces más rápido, según el algoritmo implementado. Vi un factor 10x cuando el código "C" era en realidad ensamblado para aritmética de enteros grandes, debido a los códigos de multiplicación de 64x64-> 128 que ofrece el procesador, pero Java no puede usar porque su tipo de entero más largo es el de 64 bits. Este es un caso marginal. En condiciones prácticas, las consideraciones de E / S y ancho de banda de memoria evitan que el código C sea realmente tres veces más rápido que Java.

El principal problema con las aplicaciones Java es que es enorme debido al gran tamaño de la biblioteca de tiempo de ejecución de stock. Los programas enormes llenan mucho en la memoria y tienden a intercambiarse, lo que significa que se vuelven lentos.

La razón por la que Sun JVM es grande es porque tiene un muy buen intérprete de código de bytes que funciona haciendo un seguimiento de muchas cosas. Eso significa mucha información, lo que significa memoria.

Es posible que desee ver la máquina virtual jamvm, que es un intérprete razonablemente rápido (sin código nativo) y muy pequeña. Incluso se inicia rápido.

Es información obsoleta desde los primeros días (mediados y finales de la década de 1990) de Java. Cada versión principal de Java ha introducido aceleraciones significativas en comparación con la versión anterior. Con Oracle aparentemente fusionando JRockit con JVM de Sun para Java 7, parece que esta tendencia continuará.

Comparado con muchos otros lenguajes modernos populares (Python, Ruby, PHP), Java es significativamente más rápido para la mayoría de los usos. No coincide con C o C ++, pero para muchas tareas es lo suficientemente cerca. Las preocupaciones reales de rendimiento deberían ser la cantidad de memoria que termina usando.

Inicialmente Java no era particularmente rápido, pero tampoco es demasiado lento. En estos días, Java es muy rápido. De las personas con las que he hablado, la impresión de que Java es lento proviene de dos cosas:

Tiempo de inicio de VM lento. La implementación temprana de Java tomó mucho tiempo para arrancar y cargar las bibliotecas requeridas y la aplicación en comparación con las aplicaciones nativas.
IU lenta. Early Swing fue lento. Probablemente no ayudó que la mayoría de los usuarios de Windows encontraran el Metal L & F feo por defecto.

Teniendo en cuenta los puntos anteriores, no es de extrañar que la gente tenga la impresión de que "Java es lento".

Para usuarios o desarrolladores acostumbrados a desarrollar aplicaciones nativas, o incluso aplicaciones de Visual Basic , estos dos puntos son lo más visible en una aplicación, y es la primera impresión que obtendrás sobre una aplicación (a menos que sea una aplicación que no sea GUI en la que caso solo aplica 1.).

No convencerá a un usuario de que "ejecuta código muy rápido" cuando la aplicación tarda 8 segundos en iniciarse frente a su antigua aplicación de Visual Basic que se inicia inmediatamente, incluso aunque la ejecución del código y el tiempo de inicio no estén conectados en absoluto.

Arruinar la primera impresión es una gran manera de comenzar rumores y mitos. Y los rumores y mitos son difíciles de matar.

En resumen, Java no es lento. Las personas que tienen la "actitud de Java es lenta" se basan en las primeras impresiones de Java hace más de 10 años.

Java FUE lento, en el día. Se ha vuelto mucho más rápido, debido a algunas generaciones de mejoras de rendimiento . Lo último que escuché es que generalmente está dentro del 10% de la velocidad C # - a veces más rápido, a veces más lento.

El inicio del applet de Java todavía es lento porque tienes que iniciar una JVM completa, que debe cargar todas sus clases. Algo así como arrancar otra computadora. Una vez que se inicia JVM, es bastante rápido, pero el inicio suele ser lo que la gente recuerda.

Además, hay al menos algunas personas que nunca creerán en la viabilidad de Java.

Java es definitivamente lento, especialmente para el trabajo cuantitativo.

Uso una combinación de R , Python y C / C ++ con bibliotecas optimizadas de ATLAS multiproceso. En cada una de estas lenguas puedo multiplicar una matriz de dobles de 3000 por 3000 consigo misma en alrededor de 4 segundos. Usando Colt y Parallel Colt en Java, la misma operación toma 185 segundos. Sorprendente a pesar de que estas bibliotecas de Java son paralelas en su naturaleza.

Entonces, en general, Java puro no es adecuado para el trabajo cuantitativo. Jblas parece ser la mejor biblioteca de álgebra lineal para Java ya que usa ATLAS.

Mi máquina es una HP Core 2 Duo con 3 GB de RAM. Uso Ubuntu 10.04 64 bits (Lucid Lynx).

Java es un lenguaje de alto nivel y su reputación hoy en día es tener un rendimiento a la par con otros lenguajes de alto nivel comparables.

Tiene semántica de enlace dinámico . En comparación con C ++, donde los métodos no virtuales se compilan como llamadas a funciones, incluso el mejor compilador de Java del mundo tiene que producir código que es menos eficiente. Pero también es una semántica más limpia y de más alto nivel.
No recuerdo los detalles, pero escuché en los primeros días de Java que había un mutex por objeto Java, para ser adquirido y publicado por cada método. Eso tiende a hacerlo mejor adaptado a la concurrencia, aunque desafortunadamente solo un mutex por objeto no lo protegerá de razas o bloqueos o de cualquiera de las cosas malas que pueden ocurrir en los programas concurrentes. Esa parte, si es cierta, es un poco ingenua, pero proviene de buenas intenciones. Siéntase libre de completarme con los detalles si conoce más sobre este aspecto.
Otra forma en que Java es un lenguaje de alto nivel es tener Garbage-Collection . Garbage-Collection puede ser más lenta que malloc y free para programas que asignan de una vez toda la memoria que necesitan y trabajan con eso. El problema es que, en los lenguajes que no tienen Garbage-Collection, los programadores tienden a escribir solo programas que asignan toda la memoria que necesitan a la vez y fallan si resulta que alguna constante arbitraria de tamaño máximo se ha desbordado. Entonces la comparación es de manzanas a naranjas. Cuando los programadores hacen el esfuerzo de escribir y depurar programas con asignación dinámica de estructuras encadenadas en lenguajes que no son de GC, a veces descubren que sus programas ya no son más rápidos que en un lenguaje de GC, ¡porque malloc y free no son gratuitos! También tienen sobrecarga ... Además, al no tener fuerzas de GC para especificar quién libera qué, y tener que especificar quién libera lo que a su vez en algún momento te obliga a hacer copias, cuando varias funciones van a necesitar los datos y no está claro cuál lo usará en último lugar, mientras que el copiado no habría sido necesario en un lenguaje de GC.

Java tiene la reputación de ser lento porque fue lento. Las primeras versiones de Java no tenían compilación Just In Time o, más bien, eran deficientes. Esto significaba que el código, aunque era bytecode, se interpretaba, por lo que incluso para las operaciones más simples (como agregar dos enteros), la máquina tenía que hacer todo tipo de comparaciones, referencias de punteros y llamadas a funciones. El compilador JIT ha estado mejorando constantemente; ahora está en el punto en el que si escribo el código C ++ descuidadamente y el código Java descuidadamente, Java a veces superará a C ++ porque el compilador JIT se da cuenta de que tengo algo de desreferenciación de punteros innecesarios y me ocuparé de eso.

Si desea ver qué tan grande es la diferencia que hace la compilación de JIT, consulte los puntos de referencia interpretados y no interpretados en el Juego comparativo de idiomas de computadora . (Pidigits usa una biblioteca externa para hacer todos los cálculos, de modo que el punto de referencia no cambia, ¡los otros muestran una aceleración de 6-16x!)

Entonces, esa es la razón principal. Hay una variedad de otras razones menores que no ayudaron: originalmente, el tiempo de inicio de Java era lento (ahora se arregló); las aplicaciones web en Java tardan mucho tiempo en descargarse (mucho menos cierto ahora con una banda ancha ampliamente accesible y con grandes cosas como películas que se esperan); el UI Swing no estaba (y aún no está) escrito teniendo en cuenta el rendimiento, por lo que es mucho menos rápido que los equivalentes, por ejemplo, en C ++.

La gente normalmente saca la línea "se interpreta". Porque alguna vez lo fue, y la mala prensa es transmitida por personas que desecharon Java como ''demasiado lento'' y nunca volvieron a probar versiones más nuevas.

O tal vez "las personas son idiotas" es una mejor respuesta.

La moderna Java es uno de los idiomas más rápidos, a pesar de que todavía es un recuerdo de la memoria. Java tenía una reputación de ser lento porque solía llevar mucho tiempo para que se iniciara la máquina virtual.

Si todavía crees que Java es lento , mira los resultados del juego de puntos de referencia . Código muy optimizado escrito en un lenguaje compilado anticipado (C, Fortran, etc.) puede superarlo; sin embargo, Java puede ser más de 10 veces más rápido que PHP, Ruby, Python, etc. Hay áreas específicas donde puede vencer a los lenguajes compilados comunes (si usan bibliotecas estándar).

No hay excusa para aplicaciones Java "lentas" ahora. Los desarrolladores y el código heredado / bibliotecas tienen la culpa, mucho más que el lenguaje. Además, culpen a cualquier cosa ''empresa''.

Para ser justos con el público "Java es lento", aquí hay áreas donde todavía es lento (actualizado para 2013):

Las bibliotecas a menudo se escriben para "corrección" y legibilidad, no para rendimiento. En mi opinión, esta es la razón principal por la cual Java todavía tiene una mala reputación, especialmente en el lado del servidor. Esto hace que los problemas de String sean exponencialmente peores. Algunos errores simples son comunes: a menudo se usan objetos en lugar de primitivos, lo que reduce el rendimiento y aumenta el uso de la memoria. Muchas bibliotecas Java (incluidas las estándar) crearán Cadenas con frecuencia, en lugar de reutilizar formatos mutables o más simples (char [] o StringBuffer). Esto es lento y crea toneladas de basura para recoger más tarde. Para solucionarlo, sugiero que los desarrolladores usen colecciones primitivas y especialmente las bibliotecas de Javalution, donde sea posible.
Las operaciones de cadena son un poco lentas. Java utiliza objetos de cadena incoherentes, UTF-16 . Esto significa que necesita más memoria, más acceso a la memoria y algunas operaciones son más complejas que con ASCII (C, C ++). En ese momento, era la decisión correcta para la portabilidad, pero conlleva un pequeño costo de rendimiento. UTF-8 parece una mejor opción ahora.
El acceso a la matriz es un poco más lento en comparación con C, debido a los controles de límites. La penalización solía ser grande, pero ahora es pequeña (Java 7 optimiza muchas verificaciones de límites redundantes).
La falta de acceso arbitrario a la memoria puede hacer que algunos procesos de E / S y de nivel de bits sean lentos (compresión / descompresión, por ejemplo). Esta es una característica de seguridad de la mayoría de los lenguajes de alto nivel ahora.
Java usa MUCHA más memoria que C, y si su aplicación está unida a la memoria o a un ancho de banda de memoria (caché, etc.) esto lo hace más lento. La otra cara de la moneda es que la asignación / desasignación es extremadamente rápida (altamente optimizada). Esta es una característica de la mayoría de los lenguajes de alto nivel ahora, y debido a los objetos y el uso de GC lugar de asignación de memoria explícita. Además malas decisiones de la biblioteca.
La E / S basada en flujos es lenta debido a que (IMO, opción deficiente) requiere sincronización en cada acceso de transmisión. NIO corrigió esto, pero es difícil de usar. Uno puede evitar esto haciendo leer / escribir en una matriz, en lugar de un elemento a la vez.
Java no proporciona la misma funcionalidad de bajo nivel que C, por lo que no puede usar trucos sucios de ensamblador en línea para acelerar algunas operaciones. Esto proporciona portabilidad y es una característica de la mayoría de los lenguajes de alto nivel ahora.
Es común ver las aplicaciones Java vinculadas a versiones JVM muy antiguas. Especialmente del lado del servidor. Estas antiguas JVM pueden ser increíblemente ineficientes, en comparación con las últimas versiones.

Al final, Java fue diseñado para proporcionar seguridad y portabilidad a expensas de algún rendimiento, y para algunas operaciones realmente exigentes lo demuestra. La mayor parte de su reputación de lentitud ya no se merece.

Sin embargo, hay varios lugares donde Java es más rápido que la mayoría de los otros idiomas:

La asignación de memoria y la desasignación son rápidas y económicas. He visto casos en los que es 20% MÁS RÁPIDO (¡o más!) Asignar una nueva matriz de varios kB que reutilizar una en caché.
La ejemplificación de objetos y las características orientadas a objetos son increíblemente rápidas de utilizar (más rápidas que C ++ en algunos casos), porque están diseñadas desde el principio. Esto es en parte por un buen GC en lugar de una asignación explícita (que es más amigable con muchas asignaciones de objetos pequeños). Uno puede codificar C que supere esto (haciendo rodar la administración de memoria personalizada y haciendo malloc de manera eficiente), pero no es fácil.
Las llamadas a métodos son básicamente gratuitas y, en algunos casos, más rápidas que el código de método grande. El compilador de HotSpot utiliza información de ejecución para optimizar las llamadas de método y tiene una alineación muy eficiente. Al utilizar la información de ejecución adicional, en ocasiones puede superar el rendimiento de los compiladores por adelantado e, incluso (en casos excepcionales), la inclusión manual. Compare con C / C ++ donde las llamadas a métodos vienen con una pequeña penalización de rendimiento si el compilador decide no alinearse.
La sincronización y multi-threading son fáciles y eficientes. Java fue diseñado para ser consciente de los hilos desde el principio, y se nota. Las computadoras modernas suelen tener varios núcleos, y como el enhebrado está integrado en el idioma, puede aprovecharlo muy fácilmente. Básicamente, un impulso extra de velocidad del 100% al 300% frente al código C estándar de un solo subproceso. Sí, el encriptado C cuidadosamente escrito y las bibliotecas pueden superar esto, pero eso es mucho trabajo extra para el programador.
Las cadenas incluyen longitud: algunas operaciones son más rápidas. Esto supera el uso de cadenas delimitadas por nulos (común en C). En Java 7, Oracle eliminó la optimización String.subString () porque las personas la usaban de forma estúpida y obtenían pérdidas de memoria.
La copia de matriz está altamente optimizada. En las últimas versiones, Java usa un ensamblador sintonizado a mano para System.arraycopy. El resultado es que en las operaciones de arraycopy / memcopy-heavy, he visto que mi código supera el equivalente en C con márgenes razonables.
El compilador JIT es inteligente sobre el uso de caché L1/L2 . Los programas compilados con anticipación no pueden modificar su código en tiempo real para la CPU y el sistema específicos en los que se ejecutan. JIT proporciona algunas transformaciones de bucle muy eficientes de esta manera.

Un par de otros hechos históricos contribuyeron a la reputación de "Java es lento":

Antes de la compilación de JIT (Java 1.2 / 1.3), el lenguaje solo se interpretaba, no se compilaba y, por lo tanto, era muy lento.
La compilación de JIT tomó tiempo para ser eficiente (mejoras importantes con cada versión)
La carga de clases se ha vuelto mucho más eficiente a lo largo de los años. Solía ser bastante ineficiente y lento durante el inicio.
Swing código Swing y UI no usaba hardware de gráficos nativos muy bien.
Swing es horrible. Culpo a AWT y Swing de por qué Java nunca se prendió en el escritorio.
Uso intensivo de sincronización en clases de biblioteca; versiones no sincronizadas están ahora disponibles
Los applets tardan una eternidad en cargarse, debido a que transmiten un JAR completo a través de la red y cargan la VM para arrancar.
La sincronización solía tener una gran penalización de rendimiento (esto se ha optimizado con cada versión de Java). La reflexión es aún costosa, sin embargo.

Muchas aplicaciones de escritorio de Java (estas veces: cosas como Eclipse) tienen una mala respuesta de la GUI, probablemente debido al alto consumo de memoria y al hecho de que el cargador de clases puede hacer mucho IO. Está mejorando, pero fue peor hace unos años.

A muchas (la mayoría) personas les gusta hacer generalizaciones, por lo que dicen "Java es lento" porque perciben que las aplicaciones son lentas cuando interactúan con ellas.

Para que la experiencia de la mayoría de la gente interactúe con ella, Java es lenta. Todos hemos visto esa taza de café dando vueltas en nuestro navegador antes de que surja algún applet. Lleva un tiempo hacer girar la JVM y descargar los binarios de la aplicación, y eso afecta la experiencia del usuario de una manera que se nota.

No ayuda que el lento tiempo de descarga de la JVM y el applet esté conspicuamente marcado con una taza de café Java, por lo que las personas asocian la espera con Java. Cuando Flash tarda mucho tiempo en cargarse, el desarrollador de Flash especifica la marca del mensaje de "carga", por lo que las personas no culpan a la tecnología Flash como un todo.

Todo esto no tiene nada que ver con el rendimiento de Java en un servidor o con las muchas otras formas en que Java se usa fuera del navegador. Pero es lo que la gente ve y lo que los desarrolladores que no son Java recuerdan cuando piensan en Java.

Parece que estás haciendo dos preguntas bastante diferentes:

¿Java es realmente lento, y si es así, por qué?
¿Por qué Java se percibe como lento, a pesar de que es más rápido que muchas alternativas?

El primero de estos es más o menos un tipo de pregunta "¿cuánto tiempo es una cuerda?" Todo se reduce a tu definición de "lento". Comparado con un intérprete puro, Java es extremadamente rápido. En comparación con otros lenguajes que (normalmente) se compilan en algún tipo de bytecode, compilados dinámicamente en código máquina (por ejemplo, C # o cualquier otra cosa en .NET), Java está más o menos a la par. En comparación con los lenguajes que normalmente se compilan para código de máquina puro, y tienen equipos de personas (a menudo grandes) que solo trabajan para mejorar sus optimizadores (por ejemplo, C, C ++, Fortran, Ada), Java funciona bien en algunas cosas, pero en general tiende a ser al menos algo más lento.

Mucho de esto se relaciona principalmente con la implementación; básicamente, se reduce al hecho de que un usuario está esperando mientras se ejecuta un compilador dinámico / JIT, así que a menos que tengas un programa que se ejecute por bastante tiempo para comenzar, es Es difícil justificar que el compilador dedique mucho tiempo a optimizaciones difíciles. Por lo tanto, la mayoría de los compiladores Java (y C #, etc.) no ponen mucho esfuerzo en optimizaciones realmente difíciles. En muchos casos, se trata menos de las optimizaciones que de dónde se aplican. Muchos problemas de optimización son NP completos, por lo que el tiempo que toman crece rápidamente con el tamaño del problema que se está atacando. Una forma de mantener el tiempo dentro de lo razonable es solo aplicar la optimización a algo así como una sola función a la vez. Cuando solo el desarrollador está esperando el compilador, puede permitirse tomar mucho más tiempo y aplicar la misma optimización a partes mucho más grandes del programa. Del mismo modo, el código para algunas optimizaciones es bastante peludo (y por lo tanto puede ser bastante grande). De nuevo, dado que el usuario está esperando mientras se carga ese código (y el tiempo de inicio de JVM suele ser un factor significativo en el tiempo total), la implementación tiene que equilibrar el tiempo ahorrado en un lugar con el perdido en otro, y dado el poco código beneficios de las optimizaciones peludas, mantener la JVM pequeña suele ser más beneficiosa.

Un segundo problema es que con Java, con frecuencia se obtiene una solución más o menos de "talla única". Solo por ejemplo, para muchos desarrolladores de Java, Swing es esencialmente la única biblioteca de ventanas disponible. En algo como C ++, hay literalmente docenas de bibliotecas de ventanas, marcos de aplicaciones, etc., cada uno con su propio conjunto de compromisos entre la facilidad de uso frente a la ejecución rápida, el aspecto y la sensación consistentes frente a la apariencia nativa, y así sucesivamente. El único punto real es que algunos (por ejemplo, Qt) pueden ser bastante caros (al menos para uso comercial).

En tercer lugar, una gran cantidad de código escrito en C ++ (y C incluso más) es simplemente más viejo y más maduro. En gran parte contiene un núcleo de rutinas escritas hace décadas, cuando gastar más tiempo optimizando el código era el comportamiento normal y esperado. Eso a menudo tiene un beneficio real en el código que es más pequeño y más rápido. C ++ (o C) obtiene el crédito por el código que es pequeño y rápido, pero en realidad es mucho más un producto del desarrollador y las limitaciones del momento en que se escribió el código. Hasta cierto punto, esto lleva a una profecía autocumplida: cuando las personas se preocupan por la velocidad, a menudo seleccionan C ++ porque tiene esa reputación. Pusieron tiempo y esfuerzo extra en la optimización, y se escribe una nueva generación de código rápido en C ++.

En resumen, la implementación normal de Java hace que la optimización máxima sea problemática en el mejor de los casos. Peor aún, cuando Java es visible , cosas como los kits de herramientas de ventana y el tiempo de inicio de JVM a menudo juegan un papel más importante que la velocidad de ejecución del lenguaje en sí. En muchos casos, C y C ++ también obtienen crédito por lo que realmente es el producto de simplemente trabajar más duro en la optimización.

En cuanto a la segunda pregunta, creo que es en gran medida una cuestión de naturaleza humana en el trabajo. Algunos fanáticos hacen afirmaciones bastante infladas acerca de que Java es deslumbrantemente rápido. Alguien lo prueba y descubre que incluso un programa trivial tarda unos segundos en comenzar, y se siente lento y torpe cuando se ejecuta. Pocos probablemente se molestan en analizar cosas para darse cuenta de que una gran parte de esto es el tiempo de inicio de la JVM, y el hecho de que cuando primero prueban cosas, ninguno de los códigos ha sido compilado todavía: parte del código está siendo interpretado, y algunos se compilan mientras esperan. Peor aún, incluso cuando funciona lo suficientemente rápido, la apariencia generalmente parece extraña y torpe para la mayoría de los usuarios, por lo que incluso si las mediciones objetivas mostraran tiempos de respuesta rápidos, aún parecería torpe.

Sumarlos conduce a una reacción bastante simple y natural: que Java es lento, feo y torpe. Dado el bombo que dice que es muy rápido, hay una tendencia a reaccionar de forma exagerada y concluir que es terriblemente lento, en lugar de un (más preciso) "un poco más lento, y sobre todo en circunstancias específicas". Esto generalmente es peor para un desarrollador que escribe los primeros programas en el idioma. La ejecución de un programa "hello world" en la mayoría de los idiomas aparece instantáneamente, pero en Java hay una pausa fácilmente perceptible cuando se inicia la JVM. Incluso un intérprete puro que corre mucho más despacio en bucles estrechos y que a menudo parecerá más rápido para un código como este, simplemente porque puede cargarse y comenzar a ejecutarse un poco antes.

Stefano:

He estado con Java desde el principio, así que desde mi punto de vista, la fama de ser lento fue creada por interfaces de interfaz gráfica de usuario (AWT y Swing) que no respondían y lentas, y en Applets probablemente debido a los tiempos de arranque lento adicionales del VM''s

Java ha estipulado y promovido una gran cantidad de investigación en el área de VM, y ha habido algunas mejoras, incluida la recolección de basura (puede sintonizar muchas cosas en realidad; sin embargo, a menudo veo sistemas donde solo se usan valores predeterminados) y zona activa optimización (que al principio y probablemente aún más eficiente en el lado del servidor).

Java en el backend y el nivel computacional no es tan lento. Colt es uno de los mejores ejemplos:

La última versión estable de Colt rompe la barrera de 1.9 Gflop / s en JDK ibm-1.4.1, RedHat 9.0, 2x [email protected] GHz.

Hay muchas cosas fuera de la corriente principal de Java que deberían considerarse, como Java en tiempo real o mecanismos especiales para mejorar la velocidad como Javolution , así como la compilación Ahead-Of-Time (como gcj). Además, hay IC que pueden ejecutar Java Bytecode directamente, como por ejemplo el que está en los actuales iPhones y iPods ARM Jazelle .

Creo que, en general, hoy es una decisión política (como que no hay soporte de Java en el iPhone / iPod) y una decisión contra Java como lenguaje (porque muchos piensan que es demasiado detallado).

Sin embargo, hay muchos otros lenguajes para Java VM hoy en día (por ejemplo, Python, Ruby, JavaScript, Groovy, Scala, etc.) que pueden ser una alternativa.

Personalmente sigo disfrutando de ella como una plataforma flexible y confiable, con excelentes herramientas y disponibilidad de biblioteca, que permite trabajar con todo, desde el dispositivo más pequeño (por ejemplo, JavaCard) hasta los servidores más grandes.

Un martillo es mucho más lento en el despliegue de la masa que muchas otras herramientas. No hace que el martillo sea "más lento" ni menos útil para las tareas para las que está diseñado.

Como lenguaje de programación general, Java está a la par con muchos (si no la mayoría) para una amplia gama de tareas de programación. Existen pruebas específicas y triviales para las cuales Java no superará las soluciones codificadas a mano en lenguajes menos sofisticados, los que están "más cerca del metal".

Pero cuando se trata de "aplicaciones del mundo real", Java a menudo es la herramienta correcta. Ahora, dicho esto, nada impedirá que los desarrolladores creen una solución de bajo rendimiento utilizando CUALQUIER herramienta. El uso indebido de la herramienta es un problema bien conocido (basta con ver las reputaciones de PHP y VB). Sin embargo, el diseño y la sintaxis limpios (principalmente) limpios hacen mucho para reducir el uso indebido.