Наскільки швидкий Javascript у порівнянні з Java? [зачинено]


77

Чи існують тести, які порівнюють продуктивність Javascript з Java?

ОНОВЛЕННЯ: Оскільки всі запитують, навіщо це питання, ось якийсь контекст :)

Як ви всі знаєте - сподіваюся, Javascript сьогодні не лише розміщений у веб-клієнті, але і на веб-сервері з node.js.

Його також можна запустити на мобільних телефонах і декстопах за допомогою акселератора та фонегапа.

Він також може бути значним чином використаний у веб-браузері, щоб зробити користувальницький досвід першокласним, як із настільними програмами.

Але Java теж могла це робити, запускаючи аплети на веб-клієнті та на мобільних телефонах. Це також мова для бекенда з багатьма фреймворками на вибір.

Оскільки кожен з них міг майже / повністю замінити один одного у згаданій області, я хочу знати різницю в продуктивності між ними, для кожного описаного мною випадку:

  • Клієнт: Java-аплети проти Javascript
  • Сервер: Java EE проти Javascript з Node.js + Express
  • Мобільні телефони: Java ME проти Javascript з Phonegap / Appcelerator
  • Робочий стіл: Java SE проти Javascript з Phonegap / Appcelerator

Я сподіваюся, що контекст тепер є більш зрозумілим.


2
Над чим ви працюєте, де це дві мови-конкуренти? Ви хочете використовувати JavaScript поза веб-браузером?
Джон Кугельман,

8
@John: Див. Node.js, V8, MongoDB ....
Джош К

1
Джон має рацію, без певного контексту це питання не має особливого сенсу. Є сфери, де Java і Javascript можуть "конкурувати" в наші дні, але їх все ще мало і дуже далеко. Використовуйте відповідний інструмент для роботи!
wuputah

3
Я думаю, ви запитуєте: "Привіт, кому ти більше подобається, соку чи стейку?"
Cheng Chen

1
@ Джон Кугельман. Так я. Прочитайте, де я збираюся їх використовувати, майже скрізь поза традиційним веб-браузером.
never_had_a_name

Відповіді:


125

Java і JavaScript - це мови програмування. Мови програмування - це лише купа абстрактних математичних правил. Мови програмування не швидкі. Або повільно. Вони просто є .

Продуктивність програми не має нічого спільного з мовою. Найважливішим фактором є архітектура додатків. Потім приходить алгоритмічна ефективність. Потім мікрооптимізації. Потім йде якість компілятора / інтерпретатора. Потім процесор. Можливо, ще кілька кроків між ними. Однак мова безпосередньо не грає ролі. (І звичайно, якщо ви говорите про тести, тоді також певний бенчмарк відіграє роль, а також те, наскільки добре реалізований бенчмарк, наскільки добре він запущений, чи дійсно хлопець, який виконує бенчмарк, щось знає про бенчмаркінг, а ще важливіше статистика. Крім того, точне визначення того, що ви насправді маєте на увазі"швидкий" досить важливий, оскільки він також може мати значний вплив на еталон.)

Однак мова може побічно зіграти свою роль: набагато простіше знайти та виправити вузькі місця у продуктивності в 10 рядках дуже виразного, чіткого, стислого, читабельного, добре продуманого, ізольованого коду Lisp високого рівня, ніж у 100 рядках заплутаний, низькорівневий C. (Зверніть увагу, що ці дві мови є лише прикладами. Я не хочу виділяти жодної мови.) Наприклад, Twitter сказав, що з менш виразною мовою, ніж Ruby, вони не змогли внести такі радикальні зміни в свою архітектуру за такий короткий проміжок часу, щоб вирішити їх проблеми масштабованості. І причина, чому Node.js може забезпечити таку гарну рівномірну продуктивність вводу-виводу, полягає в тому, що стандартна бібліотека JavaScript така нахабна. (Таким чином, Node.js повинен забезпечити весь сам введення-виведення, щоб вони могли оптимізувати його для рівномірного введення-виведення з нуля. Ruby та Python, наприклад, встановили парні бібліотеки вводу-виводу, які працюють так само добре, як Node.js і набагато зріліші ... але, Ruby та Python вже мають великі стандартні бібліотеки, включаючи бібліотеки вводу-виводу, які всі є синхронними та погано грати з парними бібліотеками. JavaScript не має проблем із бібліотеками вводу-виводу, які погано працюють з рівномірним введенням-виведенням, оскільки JavaScript не має бібліотек вводу-виводувзагалі .)

Але якщо ви дійсно хочете порівняти ці два, ось вам цікава точка даних: HotSpot, яка є однією з найпопулярніших, а також більш ефективних реалізацій JVM, була створена командою хлопців, до складу якої входили, серед інших людей, хлопець на ім’я Ларс Бак. Але насправді HotSpot не з’явився з повітря, він базувався на вихідному коді Anamorphic Smalltalk VM, який був створений командою хлопців, до складу якої входив, серед інших, хлопець на ім’я Ларс Бак.

V8, яка є однією з найпопулярніших, а також більш ефективних реалізацій JavaScript, була створена командою хлопців, до складу якої входив, серед інших, хлопець на ім'я Ларс Бак. Але насправді V8 не з’явився з повітря, він базувався на вихідному коді Anamorphic Smalltalk VM, який був створений командою хлопців, до складу якої входив, серед інших, хлопець на ім’я Ларс Бак.

Враховуючи, що ці два більш-менш однакові, ми можемо очікувати подібних показників. Єдина різниця полягає в тому, що в HotSpot працює понад сотня інженерів, які працюють над нею протягом 15 років, тоді як V8 має десяток інженерів, які працюють менше 5 років. Те є тільки різниця в продуктивності. Мова не йде про статичних проти динамічної типізації (Java є статичний типізованим, але більшість JVMs і , звичайно , HotSpot не роблять ніяких статичних оптимізацій взагалі, все оптимізації є чисто динамічними), інтерпретацією компіляції проти (HotSpot насправді інтерпретується з додатковим JIT компілятором, в той час як V8 є чисто складеним), високого рівня проти низького рівня. Мова йде суто про гроші.

Але я збираюся зробити ставку, що для кожної пари реалізацій Java та JavaScript, де реалізація Java швидша, я можу знайти іншу пару, де реалізація JavaScript швидша. Крім того, я, мабуть, можу утримати пару і просто використовувати інший орієнтир. Є причина, за якою Комп’ютерна Мова Бенчмарк Гра називається «грою»: вони навіть заохочують Вас прямо на власній сторінці пограти з тестами, щоб будь-яка довільна мова піднялася на вершину.


10
Ось чому я запитав: "Як швидко Javascript порівнюється з Java?"
never_had_a_name

12
>> Java та JavaScript - це обидві мови програмування. ... Мови програмування не швидкі. Або повільно. << Правда. Отже, з огляду на контекст, питання стосується реалізації мови програмування, а не мов програмування.
igouy

53
Не згодні. Багато мов визначають функції, які за задумом не можуть бути ефективно оброблені сучасними процесорами. Ось чому Java загалом буде працювати швидше, ніж Smalltalk, а добре написаний C в цілому перевершить Java. Також важливо, якщо мова має автоматичне управління пам’яттю чи ні, і якщо мова має низькорівневі структури даних (байт [], структури на мові C).
R.Moeller

2
@ R.Moeller - Це, безумовно, правда, що безліч функцій мови ускладнює оптимізацію. Однак (гіпотетичний) "справді розумний" компілятор все одно зможе перекласти (скажімо) Smalltalk в оптимальну Java, а отже, і в машинний код. (Якщо людина може це зробити, то це може зробити і досить просунутий компілятор.) Той факт, що "сьогоднішні процесори" або "сьогоднішні компілятори" не можуть цього зробити, є принципово обмеженням сучасної технології .. не мови (ів) ).
Stephen C

2
@StephenC: Насправді HotSpot - це віртуальна машина Smalltalk, тож, якби Sun / Oracle кинув усі ці гроші на Smalltalk замість Java, тоді Smalltalk був би таким же швидким, як сьогодні Java. (Насправді комерційні високопродуктивні Smalltalks і так не так вже й далеко.) Пам'ятайте: коли Java вперше вийшла, Smalltalks були набагато швидшими, ніж Java. Чорт, коли вперше вийшла Self VM (яка стала Animorphic Smalltalk VM, яка стала і HotSpot, і V8), вона була конкурентоспроможною з багатьма реалізаціями C ++, доступними на той час, і швидше, ніж деякі з них.
Jörg W Mittag

41

У мене є лише анекдот, який я повинен додати: нещодавно я відновив сервер Java calc (фінанси) у Javascript (nodejs v0.6.8). Час розробки WRT, реалізація Javascript була легкою у порівнянні з початковою реалізацією Java із значно меншою кількістю рядків коду. Це був справжній ковток свіжого повітря.

Сервер, що базується на Javascript, може розраховувати 2,4 тис. Обертів / с, тоді як сервер Java обробляє 400 + / с на тому ж обладнанні, використовуючи менше пам'яті. Я б не пов'язував збільшення швидкості із вихідною продуктивністю V8 проти Java 7, а скоріше з реалізацією. Реалізація Javascript використовує набагато менше структур даних, робить на порядок менше викликів методів і застосовує більш прямий і стислий підхід.

Що й казати, я дуже задоволений роботою node.js. І це від когось, хто був Java лише багато (9) років.


Це чудова точка даних ... дякую.
HDзберегти

8
Я думаю, ви порівнюєте підходи синхронізації та асинхронізації, але не Java та Javascript. А Node.js, будучи асинхронним, безумовно виграє проти синхронізації сервлетів та бібліотек tomcat. Але це не тому, що Javascript швидший, а тому, що асинхронізація - це краще використання ресурсів, ніж синхронізація.
Нічний воїн

2
Яких змін щодо продуктивності ви очікуєте, якщо довелося б писати іншу версію програми на Java? Чи вважаєте ви, що продуктивність програми суттєво зросте (порівняно з першою версією Java) завдяки ідеям, які ви отримали з версії JavaScript?
rwitzel

Я порівняв nodeJS з простою продуктивністю C в number-crunchingдодатках. NodeJS був лише в 2,5 рази повільніший за C.
Thevs

32

Ось декілька тестів для порівняння Javascript (V8) та скомпільованої Java:

Вони вказують на те, що Java, як правило, швидша 1 . Однак, якщо ви покопаєтесь на цих сторінках та пов’язаних ресурсах, ви помітите, що порівняти подібне з подібним дуже важко.

Цікаво, що Javascript робить значно краще, ніж Java (за певних умов) для еталону "regex-dna". Я припускаю, що це тому, що механізм регулярних виразів Javascript швидший, ніж механізм регулярних виразів Java. Це не зовсім дивно, враховуючи важливість регулярних виразів у типових додатках Javascript.

1 - Власне кажучи, ви не можете сказати, що мова X швидша за мову Y. Ви можете порівнювати лише конкретні реалізації відповідних мов. І на веб-сайті, на який я посилався, це ясно ... якщо ви хочете зайти через першу сторінку. Однак не зовсім нерозумно узагальнювати за конкретними точками даних ... і очевидною відсутністю суперечливих точок даних ... що Java, як правило, швидша за Javascript у обчислювальних завданнях. Але зворотний бік полягає в тому, що такий виступ часто не є об’єктивно важливим критерієм.


>> Я припускаю, що це тому, що механізм регулярних виразів Javascript швидший ... << З вихідним кодом програми regex-dna JavaScript V8 # 2 є посиланням на "Irregexp, нова реалізація регулярних виразів Google Chrome" blog.chromium.org /
2009/02

12

Java, очевидно.

Програмісти люблять порівнювати швидкість виконання, як якийсь пісячий вміст. Це лише одна метрика, і в більшості випадків, не найважливіша з довгих пострілів. Java - це мова, яка має поєднання достатньої швидкості майже для будь-чого, але на достатньо високому рівні, щоб отримати такі речі, як GC, яких ви зазвичай не отримуєте подібними мовами. Javascript - це мова динамічного закриття, яка чудово підходить для швидкого виконання робіт (і для програмістів FP, що застрягли в світі OO ;-)). У місцях, де було б доречно, не так багато перешкод.

Зараз я перестану понтифікувати

РЕДАГУВАТИ: для звернення до редагування у дописі

Завдяки тому, як пишеться ідіоматичний javascript (функції, що складаються з функцій), він напрочуд добре піддається асинхронному програмуванню, можливо, кращому за будь-яку іншу мову подібної популярності. Node.js блищить, коли йдеться про величезну кількість коротких з'єднань, тому javascript дуже підходить для такого роду речей.

Незважаючи на те, що node.js абсолютно чудовий, але нова гарячість насправді не означає, що він найкращий у всьому, незалежно від того, що говорить ажіотаж. Якщо додаток Java можна замінити вузлом, швидше за все, java насправді не був доречним.


9

Можливо, ні, але це насправді не має значення.

До створення JavaScript JIT від Google Chrome Java перемагала JavaScript, як тільки проблема набула достатнього масштабу, щоб подолати час завантаження.

Java як і раніше повинна круто перешкоджати JavaScript через цілочисельну чи плаваючу математику. Незалежно від того, наскільки хороший JIT, він насправді не може це компенсувати.

WebAssembly все одно переверне це.


6
Проблема PHP у Facebook стала досить великою, і тоді вони її скомпілювали. Отже ...
BrunoLM

1
Не обов’язково справедливо для останньої точки зору (можливо, це було в 2010 році?) V8 спочатку скомпілює функцію з меншою кількістю оптимізацій, а тим часом відстежує статистику типів тощо для декількох прогонів. Скажімо, ви підсумовуєте всі числа в масиві. Якщо V8 побачить, що всі попередні значення були цілими числами, він повторно скомпілює функцію, щоб використовувати інструкції машинного коду додавання цілих чисел (це "оптимістично"). Якщо на півдорозі через масив раптом з'явиться рядок, він повернеться до менш оптимізованої версії. Отже, якщо ви послідовні, це може бути досить швидко.
ShawnFumo

Є чудова розмова В’ячеслава Єгорова від початку цього року, який детально розглядає масиви у V8 (серед іншого).
ShawnFumo

А так, нарешті, це теж виправили. Думаю, ця відповідь буде поступово ставати все менш і менш правдивою з часом.
Джошуа

4

http://benchmarksgame.alioth.debian.org/u64q/javascript.html

(Не забудьте поглянути на стовпець процесора так само добре, як минулі секунди).

Відповідно до наведеного посилання, JavaScript, як зараз, є набагато повільнішим майже для всього.


3
Java використовує пам'ять у 2-3 рази майже в кожному випадку ... не здається справедливим
Esailija

1
Цей показник несправедливий. Більшість Java Perf. отримується за допомогою багатопоточності. Ви можете робити багатопотоковість у nodejs за допомогою нових процесів та конвеєрів. Але цього не вистачає у цих тестах.
Степан Яковенко

3
@Stepan - ось як ви можете внести свій внесок у програми - benchmarksgame.alioth.debian.org/play.html#contribute
igouy

-6

Вони схожі лише за назвою, ось і все. Java компілюється під час інтерпретації JavaScript (здебільшого). Навіть за допомогою своєчасного компілятора V8 Java швидше за все працює.


1
Чесно кажучи, вони набагато більше схожі, ніж просто за назвою. Для початку вони обидва мають схожу синтаксичну схожість завдяки використанню C. Крім того, код Java можна писати на JavaScript. І нарешті, Java постачається з вбудованим інтерпретатором JavaScript, щоб ви могли вбудувати JavaScript у додаток Java.
Мойсей

Чи є у вас фактичні докази цього дикого твердження "швидше у всьому"? Беручи до уваги надзвичайно різні галузі, в яких ці дві мови часто працюють, я б сказав, що будь-яка спроба сказати "швидше" потребуватиме набагато більше контексту, тому що я не купую, що Java просто швидше виходить (у всьому). Чи не використовували б ви аплет Java для, скажімо, якогось кульгавого ефекту DHTML, який JS міг робити під час сну? Аплет швидший?
Свенд,

2
@Svend: Ви не тестуєте мови, пишучи аплети або певні функції. Виконайте абстрактну математику, рекурсію, заповнення червоно-чорного дерева 10000 вузлами, обчислення з плаваючою точкою, маніпулювання рядками тощо. Ми тут не сперечаємось із використанням, ми сперечаємось, яке (в основі) працює швидше.
Джош К

Коли ви говорите в основному стосовно JS, чи говорите ви це через такі речі, як GWT? Коли JS не інтерпретується?
Естебан Арая

@Esteban Araya: Усі сучасні механізми виконання JavaScript мають компілятори. V8 - це навіть чистий компілятор, він навіть не має перекладача.
Jörg W Mittag
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.