Първо нека играя ролята на адвокат на дявола: кодът всъщност не "изпълнява" нищо (нищо сериозно имам предвид, с изключение на 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