Измерьте нагрузку на процессор приложений Javascript
Мне нужно измерить накладные расходы на дополнительные привязки событий Javascript (используя jQuery live), накладные расходы, вероятно, увеличат нагрузку на ЦП и будут очень трудно заметить из профилирования времени выполнения.
Как я могу измерить различия в загрузке ЦП между двумя различными версиями приложения Javascript?
Ответы
Ответ 1
Другим вариантом анализа является версия dynaTrace Ajax. У Resig есть быстрый обзор этого здесь. Это специфично для IE (но... что тот, у кого наихудшая производительность в большинстве случаев так...)
Взгляните, все предложения здесь замечательные, если вы смотрите на проблемы IE (некоторые приложения для интрасети блокируются для него), тогда dynaTrace - отличный и все еще бесплатный инструмент.
Ответ 2
Утилиты Chrome dev великолепны, но поскольку Chrome не является браузером, который вам когда-либо приходилось беспокоиться о производительности JS, и он много оптимизирует, это мало помогает поиску узких мест в других браузерах.
В IE 8 есть инструменты для разработчиков, которые позволяют вам профиль, поэтому вы можете найти это полезным, помимо обычного профилировщика Firebug.
Но в связи с вашей ситуацией позвольте мне сказать, что просто привязка события не приводит к большой загрузке процессора, а скорее к проблеме с памятью, но вам не стоит беспокоиться, если вы не делаете что-то необычное на вашей странице.
Также, если вы особенно обеспокоены функцией jQuery.live, позвольте мне быстро объяснить, как это работает:
Скажем, вы делаете $('#linksWrap a').live('click', fn);
- Это создает один и только один обработчик событий и привязывает его к
#linkswrap
.
- Когда вы нажимаете на одну из ссылок, событие click выворачивает дерево DOM, в итоге достигает
#linkswrap
.
- jQuery.live определяет, из какой ссылки он действительно появился. Эта информация находится в объекте Event браузера.
- jQuery.live применяет
fn
в контексте ссылки, которая была нажата
Итак, как вы видите, это действительно довольно эффективно. Браузер только присоединяет одно событие, поэтому использование памяти низкое, и ему также не нужно постоянно проверять наличие новых элементов, он использует событие bubbling в прохладном ключе.
На самом деле можно утверждать, что если вы прикрепляете тысячи событий к странице, метод .live может быть более эффективным, если вы используете хорошие селекторы. (например, .something .foo .bar.baz
требует много обхода и барботажа, но #parentOfTheLinks a.links
будет быстрым)
Ответ 3
Я думаю, что это измерение будет очень специфичным. Если с ним все в порядке, взгляните на встроенные инструменты разработчика в браузере Chrome. Существует возможность записать производительность и сравнить результаты позже. Вот Руководство по началу работы (посмотрите на профилирование и оптимизацию видео внизу).
Ответ 4
В дополнение к ответу @Ivan о Chrome Dev Tools, я бы порекомендовал вам также взглянуть на Расширение Google Speed Tracer для Chrome.
Ответ 5
Для ненаучного, но быстрого способа сравнения нагрузок ЦП вы можете запустить диспетчер задач Chrome и открыть две версии в разных вкладках/окнах. Это не поможет вам, если вы делаете оптимизацию, но она может сразу сказать вам, будет ли новая версия занимать меньше CPU.