Как различные проекты оптимизации Javascript влияют на производительность DOM?

Question

В проектах Tracemonkey, Squirrelfish и V8 много информации о компьютерных науках capital C, capital S.Касается ли какой-либо из этих проектов (или других) выполнения операций DOM, или они связаны исключительно с вычислениями на Javascript?

Answer 1

Производительность чистых операций DOM (getElementById / Tagname / Selector, nextChild и т.д.) Не изменяется, поскольку они уже выполняются на чистом C ++.

То, как улучшения движка JS повлияют на производительность, в определенной степени зависит от конкретных методов, используемых для улучшения производительности, а также от производительности DOM-> JS bridge.

Примером первого является зависимость TraceMonkey от всех вызовов функций JS.Поскольку трассировка эффективно выравнивает путь выполнения в любой точке, где JS сталкивается с кодом, который не может быть встроен (машинный код, истинная полиморфная рекурсия, обработчики исключений), трассировка прерывается, и выполнение возвращается к интерпретатору.Разработчики TM проделывают довольно большую работу по улучшению объема кода, который может быть отслежен (включая обработку полиморфной рекурсии), однако реалистично отслеживают вызовы произвольных собственных функций (например.DOM) неосуществимо.По этой причине я полагаю, что они рассматривают возможность реализации большей части DOM в JS (или, по крайней мере, в дружественной к JS манере).Тем не менее, когда код отслеживается, TM может выполнять исключительно хорошую работу, поскольку он может понизить большинство "объектов" до более эффективных и / или собственных эквивалентов (например.используйте машинные целые числа вместо реализации JS Number).

JavaScriptCore (именно там живет SquirrelFish Extreme) и V8 имеют более схожий подход в том смысле, что они оба сразу JIT весь JS-код и создают код, который является более спекулятивным (например.если вы делаете a*b они генерируют код, который предполагает a и b являются числами и возвращаются к исключительно медленному коду, если это не так).Это имеет ряд преимуществ по сравнению с трассировкой, а именно, что вы можете jit весь код, независимо от того, вызывает ли он машинный код / генерирует исключения и т.д., Что означает, что один вызов DOM не приведет к снижению производительности.Недостатком является то, что весь код является спекулятивным - TM будет встроенные вызовы Math.floor и т.д., но лучшее, что может сделать JSC / V8, было бы эквивалентно a=Math.floor(0.5) -> a=(Math.floor == realFloor) ? inline : Math.floor(0.5) это связано с затратами как на производительность, так и на использование памяти, а также не особенно выполнимо.Причиной этого является предварительная компиляция, в то время как TM использует JITs код только после его запуска (и поэтому точно знает, какая функция была вызвана), JSC и V8 не имеют реальных оснований для такого предположения и в основном должны угадывать (и в настоящее время ни один из них не пытается это сделать).Единственное, что делают V8 и JSC, чтобы попытаться компенсировать эту проблему, - это отслеживают то, что они видели в прошлом, и включают это в путь выполнения, оба используют комбинацию методов для выполнения этого кэширования, в особенно острых случаях они переписывают небольшие части потока команд, а в других случаях они сохраняют внеполосные кэши.Вообще говоря, если у вас есть код, который идет

a.x * a.y

V8 и JSC проверят "неявный тип" / "Структуру" дважды - по одному разу для каждого доступа, а затем проверят, что a.x и a.y являются обоими числами, тогда как TM сгенерирует код, который проверяет тип a только один раз, и может (при прочих равных условиях) просто размножаться a.x и a.y не проверяя, являются ли они числами.

Если вы смотрите на чистую скорость выполнения, то в настоящее время возникает нечто неоднозначное, поскольку каждый движок, похоже, лучше справляется с определенными задачами, чем другие - TraceMonkey выигрывает во многих чисто математических тестах, V8 выигрывает в сильно динамичных случаях, JSC выигрывает, если есть смесь.Конечно, хотя сегодня это верно, завтра этого может не быть, поскольку мы все усердно работаем над повышением производительности.

Другой проблемой, о которой я упоминал, был DOM<-> Стоимость привязки JS - на самом деле это может сыграть очень важную роль в производительности веб-сайта, лучшим примером этого является Safari 3.1 / 2 против Chrome в бенчмарке Dromaeo.Chrome основан на ветке Safari 3.1 / 2 WebKit, поэтому разумно предположить аналогичную производительность DOM (разница в компиляторе может вызвать некоторую степень отклонения).В этом тесте Safari 3.1 / 2 фактически превосходит Chrome, несмотря на наличие движка JS, который явно намного медленнее, в основном это связано с более эффективными привязками между JSC / WebCore (dom / rendering / etc WebKit) и V8 / WebCore

В настоящее время просмотр привязок DOM TM кажется несправедливым, поскольку они не выполнили всю работу, которую они хотят выполнить (увы), поэтому они просто возвращаются к интерпретатору :-(

..

Ммм, это продолжалось несколько дольше, чем предполагалось, поэтому короткий ответ на первоначальный вопрос - "это зависит": D

Answer 2

Это чистый JavaScript.Если только не реализован конкретный вызов метода DOM в JS, они будут иметь незначительный эффект (не говоря уже о том, что не было проделано работы по уменьшению накладные расходы о таких вызовах, однако).

Оптимизация DOM - это целый "другой набор белки обезьяны пауки рыба...В игру вступают механизмы верстки и даже рендеринга, и у каждого браузера есть своя собственная стратегия реализации и оптимизации.