Basta ya de buscar por todo internet ya que estás al sitio necesario, tenemos la respuesta que buscas sin liarte.
Solución:
Java y JavaScript son ambos lenguajes de programación. Los lenguajes de programación son solo un montón de reglas matemáticas abstractas. Los lenguajes de programación no son rápidos. O lento. Ellos solo 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 la eficiencia algorítmica. Luego micro-optimizaciones. Luego viene la calidad del compilador/intérprete. Luego la CPU. Tal vez un par de otros pasos en el medio. El lenguaje, sin embargo, no juega directamente un papel. (Y, por supuesto, si está hablando de puntos de referencia, entonces también el punto de referencia en particular juega un papel, así como qué tan bien implementado está el punto de referencia, qué tan bien se ejecuta, si la persona que realiza el punto de referencia en realidad sabe algo sobre evaluación comparativa, y aún más importante, estadísticas. También el preciso definición de lo que realmente significar por “rápido” es bastante importante, ya que también puede tener una influencia significativa en el punto de referencia).
Sin embargo, el lenguaje podría desempeñar un papel indirectamente: es mucho más fácil encontrar y solucionar los cuellos de botella de rendimiento en 10 líneas de código Lisp de alto nivel altamente expresivo, claro, conciso, legible, bien factorizado, aislado y de alto nivel, que en 100 líneas de código Lisp. C enredado y de bajo nivel. (Tenga en cuenta que esos dos lenguajes son solo ejemplos. No pretendo destacar ningún lenguaje). Twitter, por ejemplo, ha dicho que con un lenguaje menos expresivo que Ruby, no han podido realizar cambios tan radicales en su arquitectura en tan poco tiempo, para solucionar sus problemas de escalabilidad. Y la razón por la que Node.js puede proporcionar un rendimiento de E/S tan bueno es porque la biblioteca estándar de JavaScript es muy mala. (De esa manera, Node.js tiene que proporcionar toda la E/S en sí mismo, de modo que puedan optimizarlo para la E/S con eventos desde cero. Ruby y Python, por ejemplo, tienen bibliotecas de E/S con eventos que funcionan tan bien como Node.js y son mucho más maduros… pero Ruby y Python ya tienen grandes bibliotecas estándar, incluidas las bibliotecas de E/S, todas las cuales son síncronas y no funcionan bien con las bibliotecas de eventos. JavaScript no tiene el problema. de bibliotecas de E/S que no funcionan bien con E/S con eventos, porque JavaScript no tiene bibliotecas de E/S en absoluto.)
pero si tu De Verdad Si desea comparar los dos, aquí hay un punto de datos interesante para usted: HotSpot, que es una de las implementaciones de JVM más populares y también de mayor rendimiento, fue creado por un equipo de personas que incluía, entre otras personas, a un tipo llamado Lars hornear Pero en realidad, HotSpot no apareció de la nada, se basó en el código fuente de Anamorphic Smalltalk VM, que fue creado por un equipo de chicos que incluía, entre otras personas, a un tipo llamado Lars Bak.
V8, que es una de las implementaciones de JavaScript más populares y también de mayor rendimiento, fue creado por un equipo de personas que incluía, entre otras personas, a un tipo llamado Lars Bak. Pero en realidad, V8 no apareció de la nada, se basó en el código fuente de Anamorphic Smalltalk VM, que fue creado por un equipo de chicos que incluía, entre otras personas, a un tipo llamado Lars Bak.
Dado que los dos son más o menos iguales, podemos esperar un rendimiento similar. La única diferencia es que HotSpot tiene más de cien ingenieros trabajando en él durante 15 años, mientras que V8 tiene una docena de ingenieros trabajando durante menos de 5 años. Ese es el solo diferencia en el rendimiento. No es acerca static frente a escritura dinámica (Java es escrito estáticamente, pero la mayoría de las JVM y ciertamente HotSpot no hacen static optimizaciones en absoluto, todas las optimizaciones son puramente dinámicas), compilación frente a interpretación (HotSpot en realidad se interpreta con un compilador JIT adicional, mientras que V8 es puramente compilado), alto nivel frente a bajo nivel. Se trata puramente de dinero.
Pero apuesto a que por cada par de implementaciones de Java y JavaScript donde la implementación de Java sea más rápida, puedo encontrar otro par donde la implementación de JavaScript sea más rápida. Además, probablemente pueda mantenerse el par y simplemente use un punto de referencia diferente. Hay una razón llaman al Computer Languages Benchmark Game un “juego”: incluso animar usted en su propia página para jugar con los puntos de referencia para hacer que cualquier lenguaje arbitrario llegue a la cima.
Solo tengo una anécdota para agregar: Recientemente he reimplementado un servidor Java calc (finanzas) en Javascript (nodejs v0.6.8). Tiempo de desarrollo de WRT, la implementación de Javascript fue muy sencilla en comparación con la implementación original de Java con muchas menos líneas de código. Fue un soplo de aire fresco, de verdad.
El servidor basado en Javascript es capaz de calcular 2.400 operaciones por segundo, mientras que el servidor Java maneja más de 400 por segundo en el mismo hardware usando menos memoria. yo no lo haría attribute el aumento de la velocidad al rendimiento sin procesar de V8 frente a Java 7, sino más bien a la implementación. La implementación de Javascript utiliza muchas menos estructuras de datos, hace un orden de magnitud menor de llamadas a métodos y adopta un enfoque más directo y conciso.
No hace falta decir que estoy muy contento con el rendimiento de node.js. Y esto, viniendo de alguien que fue Java solo por muchos (9) años.
Aquí hay algunas pruebas que comparan Javascript (V8) y Java compilado:
- 32 bits
- 64 bits
Indican que Java es generalmente más rápido1. Sin embargo, si investiga esas páginas y los recursos vinculados, notará que es muy difícil comparar lo similar.
Curiosamente, Javascript funciona significativamente mejor que Java (bajo ciertas condiciones) para el punto de referencia “regex-dna”. Supongo que esto se debe a que el motor de expresiones regulares de Javascript es más rápido que el motor de expresiones regulares de Java. Esto no es del todo sorprendente, dada la importancia de las expresiones regulares en las aplicaciones Javascript típicas.
1 – Estrictamente hablando, no puedes decir que el idioma X es más rápido que el idioma Y. Solo puedes comparar específico implementaciones de los lenguajes respectivos. Y el sitio al que me vinculé es claro al respecto… si desea ingresar a través de la página principal. Sin embargo, no es del todo irrazonable generalizar a partir de puntos de datos específicos… y la aparente ausencia de puntos de datos contradictorios… que Java suele ser más rápido que Javascript en tareas computacionalmente intensivas. Pero la otra cara de la moneda es que ese tipo de rendimiento a menudo no es un criterio objetivamente importante.
Si conservas alguna duda y disposición de acrecentar nuestro reseña eres capaz de añadir una referencia y con deseo lo leeremos.