Тестирование прироста производительности при сжатии кода JavaScript

Я использовал 5 компрессоров JavaScript для сжатия библиотеки JavaScript (JSMin, компрессор YUI, Packer, компилятор закрытия и UglifyJS)

Теперь я знаю, что компилятор закрытия является победителем в уменьшении размера файла. Однако я также хочу проверить прирост производительности. Что было бы хорошим способом сделать это?

Я сделал простую тестовую страницу, которая использует все общедоступные методы библиотеки. Есть ли инструмент для проверки скорости этой тестовой страницы? Например. запустить его X раз в браузере и вернуть среднюю скорость загрузки.

Спасибо за ответы!


javascript packer compression yui-compressor google-closure-compiler
person Chielus    schedule 24.05.2011    source источник
comment
Что вы хотите измерить? Время загрузки через HTTP по общедоступной сети? Сколько времени парсер JavaScript тратит на синтаксический анализ текста JavaScript? Сколько времени интерпретатор тратит на обработку результата? Большинство перечисленных вами инструментов помогут только с первым (время загрузки HTTP), компилятор Closure - лишний, потому что он фактически изменяет ваш код (встраивание функций и т. Д.), Тогда как другие в основном касаются длины символа. сокращение и (в некоторых случаях) обфускация.   -  person T.J. Crowder    schedule 24.05.2011
comment
возможный дубликат Как лучше всего профилировать выполнение javascript? < / а>   -  person Felix Kling    schedule 24.05.2011
comment
Весь пакет. Я хочу проверить прирост скорости для пользователя. Секундомер от получения тестовой страницы до завершения всех общедоступных методов.   -  person Chielus    schedule 24.05.2011
comment
Некоторые говорят, что сжатый код с помощью компилятора закрытия Google действительно может снизить производительность ... Поэтому я хотел бы проверить, что дает лучшую эффективность: несжатый, сжатый или скомпилированный.   -  person Chielus    schedule 24.05.2011
comment
@Chielus воспользуйтесь поиском. Эта тема затрагивалась много раз. Лучше всего закрывающий компилятор, а самый медленный - Packer.   -  person sra    schedule 24.05.2011
comment
Все, что вам нужно знать, это размер сжатых скриптов. Время загрузки пропорционально. Браузеры должны выполнять как сжатый, так и несжатый код одинаково.   -  person HyderA    schedule 24.05.2011
comment
@gAMBOOKa: Время загрузки пропорционально. Это сложнее из-за времени установки соединения, поддержки активности и т. д., но да - как правило, меньше = быстрее. :-) Повторно сжатый и несжатый код, некоторые упаковщики вводят накладные расходы, а такие вещи, как компилятор Closure, фактически изменяют код.   -  person T.J. Crowder    schedule 24.05.2011

Ответы (4)


arrow_upward
1
arrow_downward

Не нужно усложнять это:

<html>
<head>
    <script>
    var time = new Date();
    </script>
    <script src="..."></script>
    ... more scripts ... 
</head>

<body>
<script>
    document.write("Time: " + String((new Date() - time)/1000) + " seconds");
</script>
</body>
</html>

Сценарии в <head> обычно загружаются последовательно, поэтому это должен быть разумный метод измерения времени выполнения сценария. Если у вас есть скрипты, выполняющие форму <body onload="...">, тогда вычисляйте прошедшее время в конце этой функции, а не в конце тела.

Этот метод не будет измерять время выполнения для «асинхронных» функций, выполняемых через setTimeout или setInterval, но они не должны учитываться во времени загрузки.

Альтернативой и, вероятно, более простым вариантом является использование профилировщика javascript, встроенного в Chrome или веб-инспектор Safari.

person Seth    schedule 08.06.2011

arrow_upward
0
arrow_downward

Я подозреваю, что вы ищете инструмент PageSpeed ​​.

person T.J. Crowder    schedule 24.05.2011
comment
Я знал о pagepeed, функция временной шкалы может быть полезна. Однако его можно использовать только один раз. Лучше было бы запустить его X раз и взять среднее значение. Это можно как-то сделать? - person Chielus; 24.05.2011
comment
На практике очень сложно использовать это для измерения реальных улучшений производительности без использования регулятора скорости сети. - person symcbean; 24.05.2011
comment
@symcbean: Ага. Или мой эквивалент сетевого дросселя: медленный VPS-сервер где-то на 100 Мбит (или даже 10 Мбит) соединении. :-) - person T.J. Crowder; 24.05.2011
comment
Необязательно быть точным, просто нужно сравнить компрессоры. - person Chielus; 24.05.2011

arrow_upward
0
arrow_downward

Используйте PageSpeed ​​или YSlow в firefox или HTTPAnaylser в IE, чтобы проверить разницу во времени загрузки.

person sushil bharwani    schedule 24.05.2011

arrow_upward
0
arrow_downward

Это действительно зависит от того, что вашей аудитории больше всего нравится на сайте. Пора появиться на экране? Время до завершения загрузки? Плавность анимации? Интерактивная отзывчивость? Или грубая скорость расчета?

Вы должны профилировать свой сайт, используя различные минификаторы, в зависимости от наиболее важных показателей.

Боковое примечание: компилятор Closure в простом режиме дает только минимальное ускорение. Размер файла уменьшается, но программа JavaScript остается прежней. Чтобы добиться значительного сокращения кода и оптимизации скорости, вам необходимо использовать расширенный режим.

person Stephen Chung    schedule 25.05.2011