Previous Entry Share Next Entry
2016-01

when javascript libraries claim they're fast it's a lie

уже не первый раз сталкиваюсь с ситуацией, что что-то собранное через emscripten существенно быстрее pure-js версии (не только на V8, mobile safari/mobile ie показывают ту же картину), даже с поправкой на всякий маршалинг и бредовые ситуации когда оно на выходе вынуждено выдавать строки которые надо потом отпарсить обратно

This entry was originally posted at http://wizzard.dreamwidth.org/469018.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
justy_tylor March 28th, 2016
Интересно. Теоретически к этому и так всё шло, но в практике веба возможны любые случайные искажения.

Проявляется на сторонних библиотеках с хз какой оптимизацией, или уже на своём коде?

wizzard0 March 29th, 2016
на своем тоже. ну это математика всякая, понятно, но за оптимизаторы обидно

the__listener March 28th, 2016
А здесь надо смотреть на код.
Стандартные JS-функции - жутко медленные, а обычно используют их.
(Например, разница в скорости Array.forEach и for (var i = 0, l = array.length; i < l; i++) два года назад, доходила до 25 раз не в пользу forEach - и покажите мне того, кто сейчас пользует for, если есть forEach ?).

nponeccop March 29th, 2016
К чести стандартных функций, у них по спецификации дебильная семантика (вроде итерации по массиву который в процессе этой же итерации модифицируется), и они быстрее не могут.

Ну, и есть всякие underscore:

https://github.com/jashkenas/underscore/blob/51d93a941cd348bd84a42268135aaa492d5866a9/underscore.js#L159

реимплементация форыча с быстрой семантикой

Но хорошо бы разобрать код на кирпичики и посмотреть, где же жопа. Может, гхц генерит какие-то невероятные фьюжены.

wizzard0 March 29th, 2016
дебильная семантика да, но даже если писать чистую математику то банальное использование структурок уже даёт слив по сравнению с тем чтобы unsafely лопатить элементы int32array похожим образом на то как emscripten генерит :(

the__listener March 29th, 2016
Ну, помимо того что я лично не люблю underscore, там есть свои тонкости.

_.each не совместим с forEach. Если делать его совместимым, то скорость будет еще меньше, если не делать - проще впихнуть свой полифилл в Array.prototype и получить все то же самое, но без underscore и без модификаций.

Дело совсем не в том, что длина массива может меняться в процессе выполнения (нужно просто не кешировать длину массива, и это медленнее на 0.5% или около того). Тонкость в том, что массивы могут быть "дырявыми" - и проверка существования элемента в массиве - штука очень медленная.

Т.е., если в проекте есть запрет использования дырявых массивов - проще заоверрайдить forEach, чем тащить какие-то невнятные библиотеки, написанные непонятно кем.

slonopotamus March 29th, 2016
дырявых массивов


Как это?

nponeccop March 29th, 2016
Технически массив - это обычный объект с пропертями... и как любых пропертей, индексов в массиве может не быть.

> var a = [1,2,3]
undefined
> delete a[1]
true
> 0 in a
true
> 1 in a
false
> a
[ 1, , 3 ]
>
Ну и по спецификации требуется различать [1, , 3] и [1, undefined, 3]:
> a.forEach(console.log.bind(null, "foo"))
foo 1 0 [ 1, , 3 ]
foo 3 2 [ 1, , 3 ]
undefined
> [1, undefined, 3].forEach(console.log.bind(null, "foo"))
foo 1 0 [ 1, undefined, 3 ]
foo undefined 1 [ 1, undefined, 3 ]
foo 3 2 [ 1, undefined, 3 ]
undefined
>

slonopotamus March 29th, 2016
Ну если ввести понятие "еще более undefined чем просто undefined" и заполнять им дырки, то в принципе особых проблем вроде нет. Правда такой forEach уже проблематично написать на самом js, т.к. в языке этого понятия нет.

nponeccop March 29th, 2016
Это чушь, ничего не надо вводить. В языке есть понятие проперти и есть оператор `in`, тестирующий наличие-отсутствие (и Object.prototype.hasOwnProperty)

Тут рядом уже пишут, что этот тест (перевод числа в строку и скармливание функции тестирования) отъедает кучу цпу

slonopotamus March 30th, 2016
Чушь - реализовывать массив на базе HashMap'а.

nponeccop March 30th, 2016
Вы путаете семантику и реализацию, и в решении задачи спорите с её условием, Двойка.

kurumpa March 30th, 2016
> Ну если ввести понятие "еще более undefined чем просто undefined" и заполнять им дырки, то в принципе особых проблем вроде нет.

Вся суть JS

nponeccop March 29th, 2016
Имхо все предложенные решения более упороты, чем андерскор.

slonopotamus March 29th, 2016
вроде итерации по массиву который в процессе этой же итерации модифицируется


Я встречал три способа обработки этого: никак не учитывать, детектировать и бросать эксепшен, делать copy-on-write. А что делает forEach в js?

sashman March 28th, 2016
dd.js

zerkms March 28th, 2016
Ну ты же знаешь, что emscripten генерит asm.js, который сам по себе очень ограничен, но предоставляет кучу гарантий, по которым "легко" оптимизировать.

А на старых движках разница скорее всего должна быть как раз более заметна: потому как существование в них простых оптимизаций более вероятно, чем сложных.

wizzard0 March 29th, 2016
та знаю. просто печалька, я люблю джиттеры, высокоуровневые языки и все такое)

wizzard0 March 29th, 2016
просто слишком уж у жс калечная runtime semantics видимо

  • 1
?

Log in

No account? Create an account