Почему JavaScript работает быстрее, чем С++?

Да, вы не ослышались. Глючный, тупой, тормознутый JavaScript работает быстрее, чем С++. Подождите тянуться к return userKarmaVote(), дайте мне возможность всё объяснить. Адвокат!

Есть три вида лжи ^[1]

Есть такой проект под названием Benchmarks Game ^[2]. Ребята написали программы (обход бинарных деревьев, n-body и т.д.) на всех популярных языках программирования и разработали методику измерения скорости и потребления памяти. Прежде чем читать дальше, просьба ознакомиться с методологией измерений ^[3].
Реализация каждого алгоритма подробно описана (например, nbody ^[4]). Это Open source и если вы считаете, что какой-то алгоритм реализован не самым оптимальным способом, то можете предложить собственное решение.

Из всех интерпретируемых языков, JavaScipt работает быстрее других. Он в пять раз быстрее ^[5], чем Phyton и Ruby (в том числе JRuby).

На сегодняшний день JavaScript — это самый быстрый интерпретируемый язык в мире.
Возвращаясь к C++ — по алгоритму regexdna ^[6] JavaScipt отрабатывает чуть быстрее, чем C++. При этом нагружает CPU в два раза меньше, хотя и потребляет в два раза больше ^[7] памяти.
По другим алгоритмам JavaScript, естественно, отрабатывает медленнее C++, но учитывая что они изначально в разных весовых категориях (компилируемый язык со строго типизацией против интерпретируемого языка с динамической), разница не такая уж большая.

Почему JavaScript такой быстрый?

Интерпретаторы для Python/Ruby были написаны ограниченным числом людей. Эти люди возможно безумно талантливы, но на стадии разработки у них не было никакой конкуренции. Они конкурировал только с собой — со своими представлениями о скорости и качестве. Интерпретатор же для JS родился в конкурентной борьбе лучших умов мира. Mozilla разработала SpiderMonkey, Google разработал V8, Microsoft открыли Chakra. Все они работали в жесточайшей конкурентной борьбе.

Когда у команды NodeJS встал вопрос о выборе движка для JS, они просто посмотрели бенчмарки ^[8], увидели что V8 намного быстрее и выбрали его. Если завтра Chakra от Microsoft будет работать быстрее Google V8, то не будет никакой проблемы перейти на него ^[9].

Почему JavaScript такой медленный?

Как было сказано выше, JavaScript как язык — быстрый. Однако, считается что «нативное» предназначение JS — манипуляции с DOM. На самом деле это уже давно не так и JS успешно используется на сервере (NodeJS), в мобильных устройствах и даже в микроконтроллерах. Но речь не об этом. Речь о том, что когда вы с помощью JavaScript работаете с DOM, то тормозит не JS, а DOM. Есть много причин, почему DOM такой медленный, но я позволю себе сузить фокус только на одной причине. Проблема в самой спецификации HTML. В разделе 1.1.1 The DOM Structure Model ^[10] есть следующий абзац:

...objects in the DOM are live; that is, changes to the underlying document structure are reflected in all relevant NodeList and NamedNodeMap objects...

Смысл в том, что объекты в дереве DOM — «живые». Это означает, что при любом изменении любой части DOM, эти изменения волшебным образом отражаются в каждом объекте DOM.
Крупные кампании, такие как Flipboard упорно боролись с лагами DOM. В итоге у них ничего не получилось и они смогли добиться 60 FPS ^[11] только заменив DOM на Canvas. JavaScript никуда не делся, а лаги пропали. По этой же причине Netflix отказалась от DOM ^[12] на своих TV-приставках, а Реакту пришлось придумывать свой «виртуальный DOM».

Еще раз — JavaScript на клиенте не лагает. Лагает медленный DOM (точнее манипуляции с DOM). Не важно чем вы будете менять DOM — джава-скриптом или ассемблером. DOM все равно будет притормаживать. Именно из-за тормазнутости DOM, JavaScript стал считаться медленным языком. Это историческая несправедливость и от нее давно пора избавиться.

WebAssembly

В этой связи у многих существуют неоправданные ожидания от прихода WebAssembly. Дескать, придет WebAssembly порядок наведет и мы наконец-то откажемся от «тормознутого» JS. Во-первых, даже после прихода WebAssembly, работа с DOM останется за JavaScript. Да, какие-нибудь фреймворки получат возможность перенести тяжелую логику на C/C++, но суммарный прирост от этого будет минимальным. Во-вторых, когда WebAssembly сможет ^[13] напрямую манипулировать DOM'ом минуя JS, прироста по скорости не будет, т.к. тормозит DOM, а не JS.

Хейт

Я понимаю, что скорость работы — не главный критерий оценки языка. Нужно учитывать потребление памяти, нагрузку на CPU и т.д. Я понимаю, что одно дело скорость работы каких-то академических алгоритмов, а другое дело скорость работы настоящего продакшн-приложения. Я понимаю, что кроме алгоритмов есть еще паттерны и подходы, и что ваш асинхронный ASP.NET работает не намного медленнее ^[14] асинхронного NodeJS.

Однако, JavaScript уже достаточно подвергся нападкам (заслуженным и незаслуженным) за свое «странное» поведение, за свое отношение к типах, к наследованию и т.д. Но вешать на него еще и ярлык тормознутости — это уже перебор.

Автор: zapolnoch

Источник ^[15]