Чому JavaScript працює швидше, ніж С++?



Так, ви не помилилися. Глючний, тупий, тормознутый JavaScript працює швидше, ніж С++. Зачекайте тягнутися до return userKarmaVote(), дайте мені можливість все пояснити. Адвокат!

Є три види брехні
Є такий проект під назвою Benchmarks Game. Хлопці написали програми (обхід бінарних дерев, n-body і т. д.) на всіх популярних мовах програмування і розробили методику вимірювання швидкості і споживання пам'яті. Перш ніж читати далі, прохання ознайомитися з методологією вимірювань.
Реалізація кожного алгоритму докладно описана (наприклад, nbody). Це open-source і якщо ви вважаєте, що якийсь алгоритм реалізований не самим оптимальним способом, то можете запропонувати власне рішення.

З усіх інтерпретованих мов, JavaScipt працює швидше за інших. Він в п'ять разів швидше, ніж Python і Ruby (у тому числі JRuby).



На сьогоднішній день JavaScript — це найшвидший інтерпретується в microsoft мова в світі.
Повертаючись до C++. За алгоритмом regexdna JavaScipt відпрацьовує трохи швидше, ніж C++. При цьому навантажує ПРОЦЕСОР в два рази менше, хоча і споживає в два рази більше пам'яті.
За іншими алгоритмами JavaScript, природно, відпрацьовує повільніше C++, але враховуючи що вони спочатку в різних вагових категоріях (компільований мову зі строго типізацією проти интерпретируемого мови з динамічною), різниця не така вже велика.

Чому JavaScript такий швидкий?
Інтерпретатори для Python/Ruby були написані обмеженим числом людей. Ці люди можливо шалено талановиті, але на стадії розробки у них не було ніякої конкуренції. Вони змагалися тільки з собою, зі своїми уявленнями про швидкості і якості. Інтерпретатор для JS народився в конкурентній боротьбі кращих умів світу. Mozilla розробила SpiderMonkey, Google розробив V8, Microsoft відкрили Chakra. Всі вони працювали в жорстокій конкурентній боротьбі.

Коли у команди NodeJS постало питання про вибір движка для JS, вони просто подивилися бенчмарки, що побачили V8 набагато швидше і вибрали його. Якщо завтра Chakra від Microsoft буде працювати швидше Google V8, то не буде ніякої проблеми перейти на нього.

Чому JavaScript такий повільний?
Як було сказано вище, JavaScript як мова — швидкий. Однак, вважається, що «нативне» призначення JS — маніпуляції з DOM. Насправді це вже давно не так і JS успішно використовується на сервері, у мобільних пристроях і навіть в мікроконтролерах. Але мова не про це. Мова про те, що коли ви за допомогою JavaScript працюєте з DOM, то гальмує не JS, а DOM. Є багато причин, чому DOM такий повільний, але я дозволю собі звузити фокус лише з однієї причини. Проблема в самій специфікації HTML. У розділі 1.1.1 The DOM Structure Model є такий абзац:
...objects in the DOM are live; that is, changes to the транспортний document structure are reflected in all relevant NodeList and NamedNodeMap objects...
Сенс в тому, що об'єкти в дереві DOM — «живі». Це означає, що при будь-якій зміні будь-якої частини DOM, ці зміни чарівним чином відображаються в кожному об'єкті DOM.
Великі кампанії, такі як Flipboard завзято боролися з лагами DOM. В результаті у них нічого не вийшло і вони змогли домогтися 60 FPS тільки замінивши DOM на Canvas. JavaScript нікуди не подівся, а лаги пропали. З цієї ж причини Netflix відмовилася від DOM на своїх TV-приставках, а Реакту довелося вигадувати свій «віртуальний DOM».

Ще раз — JavaScript на стороні клієнта не лагает. Лагает повільний DOM (точніше маніпуляції з DOM). Не важливо, чим ви будете міняти DOM — джава-скриптом або ассемблером. DOM все одно буде пригальмовувати. Саме із-за тормознутости DOM, JavaScript став вважатися повільним мовою. Це історична несправедливість і від неї давно пора позбутися.

WebAssembly
У зв'язку з цим у багатьох існують невиправдані очікування від приходу WebAssembly. Мовляв, прийде WebAssembly порядок наведе і ми нарешті-то відмовимося від «тормознутого» JS. По-перше, навіть після приходу WebAssembly, робота з DOM залишиться за JavaScript. Так, якісь фреймворки (типу AngularJS) отримають можливість перенести важку логіку на C/C++, але сумарний приріст від цього буде мінімальним. По-друге, коли WebAssembly зможе безпосередньо маніпулювати DOM'ом минаючи JS, приросту в швидкості не буде, оскільки гальмує DOM, а не JS.

Хейт
Я розумію, що швидкість роботи — не головний критерій оцінки мови. Потрібно враховувати споживання пам'яті, навантаження на CPU і т. д. Я розумію, що одна справа швидкість роботи якихось академічних алгоритмів, а інша справа швидкість роботи цього продакшн-додатки. Я розумію, що крім алгоритмів є ще патерни і підходи, і що ваш асинхронний ASP.NET може працювати швидше асинхронного NodeJS.

Однак JavaScript вже досить піддався нападкам (заслуженим і незаслуженим) за свою «дивну» поведінку, за своє ставлення до типах, до спадкування і т. д. Але вішати на нього ще й ярлик тормознутости — це перебір. Зупиніться!

Джерело: Хабрахабр
  • avatar
  • 0

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.