1) Eval медленнее большинства операций языка потому что занимается синтаксическим разбором, а это довольно не быстрая вещь. Но eval не будет работать медленнее (так чтобы это было заметно) разбора того же [объема] js-кода заключенного в тег script. В любом случае можно реорганизовать packer, так чтобы он писал распакованный код в тег скрипт, -- и тогда на eval уж точно не попеняешь.
2) А вот насчет сборщика мусора совсем интересно -- что-же, если я выделю объем памяти эквивалентный объему занимаемому packerнутому скрипту, (создав, например, здоровенный массив, или лучше строку) -- я гарантированно получу те же тормоза?
Alexander Ulizko
· 11 months ago
1) Возможно, возможно. Вообще, по субъективным ощущениям eval теряет скорость не только на синтаксическом разборе - очень уж по разному он работает в разных браузерах. Но в любом случае, код, пожатый packer'ом, будет работать медленней даже и без eval - он ведь предполагает вычисление перед работой.
2) Насколько говорит мой опыт - да. Особенно плотно я столкнулся с этим, когда делал поиск и сортировку в этом проекте. Очень четко видно, что, если кешировать промежуточные результаты, то при достаточно большом увеличении кеша, движок JS просто парализуется. Исходя из этого, я составил для себя такое правило - если использование кеша не критично с точки зрения алгоритма (и размер кеша предпожительно большой), то быстрее будет вывести значение заново, нежели кешировать его.
Smoke
· 11 months ago
а есть еще извраты которые дебажа пакованые скрипты? оО
Alexander Ulizko
· 11 months ago
Ну вот прямо сейчас не знаю, но не так давно - полгода-год назад и мне приходилось :) В то время мы еще пользовались richfaces, огребая по этому поводу кучу проблем.
All Comments
1) Eval медленнее большинства операций языка потому что занимается синтаксическим разбором, а это довольно не быстрая вещь. Но eval не будет работать медленнее (так чтобы это было заметно) разбора того же [объема] js-кода заключенного в тег script.
В любом случае можно реорганизовать packer, так чтобы он писал распакованный код в тег скрипт, -- и тогда на eval уж точно не попеняешь.
2) А вот насчет сборщика мусора совсем интересно -- что-же, если я выделю объем памяти эквивалентный объему занимаемому packerнутому скрипту, (создав, например, здоровенный массив, или лучше строку) -- я гарантированно получу те же тормоза?
2) Насколько говорит мой опыт - да. Особенно плотно я столкнулся с этим, когда делал поиск и сортировку в этом проекте. Очень четко видно, что, если кешировать промежуточные результаты, то при достаточно большом увеличении кеша, движок JS просто парализуется. Исходя из этого, я составил для себя такое правило - если использование кеша не критично с точки зрения алгоритма (и размер кеша предпожительно большой), то быстрее будет вывести значение заново, нежели кешировать его.
В то время мы еще пользовались richfaces, огребая по этому поводу кучу проблем.