47 votos

¿Qué tan rápido es de Javascript en comparación con Java?

Hay pruebas que comparan el rendimiento de Javascript con Java?

ACTUALIZACIÓN: Desde que todo el mundo se pregunta por qué el infierno esta pregunta, aquí es un poco de contexto :)

Como todos ustedes saben - espero - Javascript hoy en día no sólo residen en el cliente web, sino también en el servidor web con node.js.

También podría ser ejecutada en teléfonos móviles y dekstops con appcelerator y phonegap.

También podría ser utilizado de manera sustancial en el navegador web para hacer la experiencia de usuario de primera clase como con las aplicaciones de escritorio.

Pero Java podría hacer estas cosas, la ejecución de applets en el cliente web, y en los teléfonos móviles. Es también un lenguaje para el backend con muchos marcos para elegir entre.

Ya que cada uno de ellos casi se podría/sustituir por completo el uno al otro en la mencionada área, quiero saber la diferencia de rendimiento entre ellos, para todos los casos que se describen:

  • Cliente: Applets de Java vs Javascript
  • Servidor: Java EE vs Javascript con Node.js + Express
  • Teléfonos móviles: Java ME vs Javascript con Phonegap / Appcelerator
  • Escritorio: Java SE vs Javascript con Phonegap / Appcelerator

Espero que el contexto es más claro ahora.

101voto

Jörg W Mittag Puntos 153275

Java y JavaScript son ambos lenguajes de programación. Los lenguajes de programación son sólo un montón de matemática abstracta reglas. Los lenguajes de programación no son rápidos. O lenta. Ellos simplemente son.

El rendimiento de una aplicación no tiene nada que ver con el idioma. El factor más importante es la arquitectura de la aplicación. Luego viene algorítmica de la eficiencia. A continuación, micro-optimizaciones. Luego viene la calidad del compilador/intérprete. El uso de CPU. Tal vez un par de pasos en el medio. El lenguaje, sin embargo, directamente no jugar un papel. (Y, por supuesto, si estamos hablando de los puntos de referencia, entonces también el parámetro en particular juega un papel importante, así como la forma en que se implementan bien, el punto de referencia es, lo bien que ejecutar es, si el tipo que se realiza en el punto de referencia realmente sabe algo acerca de la evaluación comparativa, y aún más importante estadísticas. También, la precisa definición de lo que realmente significa por "rápido" es bastante importante, ya que también puede tener una influencia significativa en el índice de referencia.)

Sin embargo, el lenguaje podría indirectamente jugar un papel: es mucho más fácil de encontrar y solucionar los cuellos de botella en 10 líneas de muy expresiva, claro, conciso, fácil de leer, bien factorizada, aislado, alto nivel de código Lisp, que en 100 líneas de tangled, de bajo nivel C. (tenga en cuenta que estas dos lenguas son sólo ejemplos. No me refiero a solo cualquier idioma). Twitter, por ejemplo, han dicho que con un menor de lenguaje expresivo que el Rubí, que no habría sido capaz de hacer cambios radicales en cuanto a su arquitectura en un espacio tan corto de tiempo, para solucionar sus problemas de escalabilidad. Y la razón por la que Node.js es capaz de proporcionar tales buena evented rendimiento de e/S es debido a que JavaScript de la biblioteca estándar es tan malo. (De esa manera, Node.js tiene que proporcionar todos los I/O de sí mismo, así que puede optimizar para evented de e/S de la tierra para arriba. Ruby y Python, por ejemplo, han evented I/O bibliotecas que funcionan igual de bien como Node.js y son mucho más madura ... pero, Ruby y Python ya tienen grandes bibliotecas estándar, incluyendo e/S de las bibliotecas, todos los cuales son sincrónicos y no juegan bien con evented bibliotecas. JavaScript no tiene el problema de I/O bibliotecas que no juegan bien con evented de e/S, debido a que JavaScript no tiene I/O bibliotecas en todos.)

Pero si usted realmente desea comparar las dos, he aquí un interesante punto de datos para usted: HotSpot, que es uno de los más populares, y también más eficientes implementaciones de JVM por ahí, fue creado por un equipo de chicos que incluía, entre otras personas, un chico llamado Lars Bak. Pero, en realidad, HotSpot no aparecen de la nada, estaba basada en el código fuente de la Anamórfico Smalltalk VM, el cual fue creado por un equipo de chicos que incluía, entre otras personas, un chico llamado Lars Bak.

V8, que es uno de los más populares, y también más eficientes las implementaciones de JavaScript por ahí, fue creado por un equipo de chicos que incluía, entre otras personas, un chico llamado Lars Bak. Pero, en realidad, V8 no aparecen de la nada, estaba basada en el código fuente de la Anamórfico Smalltalk VM, el cual fue creado por un equipo de chicos que incluía, entre otras personas, un chico llamado Lars Bak.

Dado que los dos están más o menos la misma, podemos esperar un rendimiento similar. La única diferencia es que el punto tiene más de un centenar de ingenieros trabajando en él durante 15 años, mientras que el V8 tiene una docena de ingenieros que trabajan por menos de 5 años. Esa es la única diferencia en el rendimiento. No se trata de estática versus dinámica de escribir (Java es de tipo estático, pero la mayoría de la Jvm y ciertamente HotSpot hacer sin estática optimizaciones de ningún tipo, todas las optimizaciones son puramente dinámico), compilación versus interpretación (HotSpot es en realidad interpretada con un compilador JIT, mientras que el V8 es puramente compilado), de alto nivel frente a bajo nivel. Es puramente acerca del dinero.

Pero yo voy a apostar que para cada par de Java y las implementaciones de JavaScript donde la implementación de Java es más rápido, puedo encontrar otra pareja donde el código JavaScript de la aplicación es más rápida. También, es probable que pueda mantener a la pareja y sólo tiene que utilizar un diferente punto de referencia. Hay una razón por la llamada de los Lenguajes Informáticos de Referencia del Juego de un "juego": incluso animar a la derecha en su propia página para jugar con los puntos de referencia para hacer cualquier idioma ascenso a la cima.

28voto

kls Puntos 171

Sólo tengo una anécdota para agregar: recientemente he puesto una aplicación calc del servidor (finanzas) en Javascript, nodejs v0.6.8). WRT tiempo de desarrollo, el código Javascript de la aplicación era una brisa en comparación con el original de la implementación de Java con muchas menos líneas de código. Era como un soplo de aire fresco, de verdad.

Basado en Javascript servidor es capaz de calc a través de 2.4 k oficios/seg, mientras que el servidor de Java maneja 400+/seg en el mismo hardware que utiliza menos memoria. Yo no atribuyen el aumento de la velocidad de materias primas V8 vs Java 7 de rendimiento, sino más bien a la aplicación. El código Javascript de la aplicación utiliza mucho menos estructuras de datos, no de un orden de magnitud menor número de llamadas a métodos y toma una dirección más directa y concisa enfoque.

Huelga decir que estoy muy contento con el rendimiento de node.js. Y esto, viniendo de alguien que fue solo Java para muchos (9) años.

22voto

Stephen C Puntos 255558

Aquí están algunas pruebas de comparación de Javascript (V8) y compilado de Java, y que indican que Java es generalmente más rápido1. Sin embargo, si usted cavar a su alrededor con esa página y los recursos vinculados, te darás cuenta de que es muy difícil comparar de igual a igual.

Curiosamente, Javascript significativamente mejor que el de Java (bajo ciertas condiciones) para las "expresiones" de adn de referencia. Mi conjetura es que esto es debido a que el Javascript regex motor es más rápido que el de Java regex motor. Esto no es del todo sorprendente, dada la importancia de las expresiones regulares en las típicas aplicaciones Javascript.

1 - Estrictamente hablando, no se puede decir que el lenguaje X es más rápido que el lenguaje Y. sólo Se puede comparar específicos de las implementaciones de los idiomas respectivos. Y el sitio que enlaza a es claro acerca de eso ... si se puede ir a través de la página de inicio. Sin embargo, no es enteramente razonable generalizar a partir de puntos de datos específicos ... y la aparente ausencia de contradictorio puntos de datos ... que Java es típicamente más rápido de Javascript en tareas de cálculo intensivo. Pero la otra cara de la moneda es que este tipo de rendimiento no es a menudo un objetivamente criterio importante.

5voto

Matt Briggs Puntos 20291

Java, obviamente.

Los programadores de amor para comparar la velocidad de ejecución como una especie de mea contenido. Es sólo una métrica, y la mayoría de las veces, no la más importante por un tiro largo. Java es un lenguaje que tiene una mezcla de ser lo suficientemente rápido como para casi todo, pero lo suficientemente alto nivel que cosas como GC, que no se acostumbra en lenguajes similares. Javascript es una dinámica de cierre de la lengua que es ideal para realizar tareas de forma rápida (y para FP programadores atascado en una OO mundo ;-) ). No hay mucho en el camino de la intersección en los espacios donde sea apropiado.

Voy a dejar de pontificar ahora

EDIT: a la dirección de la edite en el post

Debido a la forma en la que uno escribe idiomáticas javascript (funciones compuestas de funciones), se presta sorprendentemente bien a la programación asincrónica, probablemente mejor que cualquier otro lenguaje de similar popularidad. Node.js brilla cuando se trata de una enorme cantidad de conexiones rápidas, así que javascript es un ajuste muy grande para ese tipo de cosas.

Mientras node.js es absolutamente empapado en impresionante, siendo el nuevo calor, en realidad, no quiere decir que sea el mejor en todo, no importa lo que la publicidad dice. Si una aplicación java es reemplazable por nodo, las posibilidades son java no estaba muy adecuado en el primer lugar.

4voto

Joshua Puntos 13231

Probablemente no, pero realmente no importa.

Antes de Google Chrome JavaScript JIT, Java iba a ganar más de JavaScript tan pronto como el problema se lo suficientemente grande como para superar el tiempo de carga.

De Java que todavía rotunda derrota de JavaScript debido a entero vs flotador de matemáticas. No importa lo bueno que el JIT no puede realmente hacer esto.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X