Сначала позвольте мне сыграть в адвоката дьявола: код на самом деле ничего не «выполняет» (ничего серьезного, я имею в виду, кроме JS Packer). По сути, это определение функций, объектов и свойств.
JS Packer создает не код JavaScript, а сжатый текст, который необходимо распаковать во время выполнения. Вот почему это намного медленнее. Google Closure с помощью Advanced Optimization заменяет идентификаторы, когда это возможно. Таким образом, при разборе сценария уже должно быть преимущество в производительности.
Тем не менее, можно пожертвовать производительностью ради размера кода. Одним из примеров является замена true
и false
на !0
и !1
. Хотя это зависит от движка JavaScript. Могло быть оптимизировано движком до первого вызова, после него, после нескольких вызовов, никогда... кто знает ;)
Новые результаты
Тем временем я профилировал и понял, что забыл одну вещь: сборку мусора. Этого влияния может быть достаточно, чтобы объяснить некоторые различия между скриптами и браузерами (разные движки!).
Объедините это с тем фактом, что код мало что делает, и у вас есть что-то. В одном тесте у меня было процессорное время для сборки мусора около 3% для несжатого и 9%(!) для JSMin. Это означает совершенно разные результаты для почти одинакового кода.
Еще новые результаты
Когда вы сначала запускаете JSMin, он быстрее, чем несжатый. Я пробовал это несколько раз и всегда получал один и тот же результат. Это подтверждает предыдущие выводы. Теперь я уверен, что мы нашли решение.
person
a better oliver
schedule
17.03.2013
a = 'getElementById'; document[a]();
), которые, вероятно, имеют очень разные характеристики производительности. - person deceze♦   schedule 17.03.2013