Para së gjithash, mos i krahasoni kurrë gjëra të tilla për arsye të performancës. Math.round është padyshim më e lehtë për sytë sesa window.Math.round, dhe nuk do të shihni një rritje të dukshme të performancës duke përdorur njërën ose tjetrën. Pra, mos e turbulloni kodin tuaj për rritje shumë të lehta të performancës.
Megjithatë, nëse jeni thjesht kurioz se cili është më i shpejtë... Nuk jam i sigurt se si shikohet shtrirja globale "nën kapuç", por do të hamendësoja se qasja në window është njësoj si qasja në Math (window dhe Math jetojnë në të njëjtin nivel, siç dëshmohet nga window.window.window.Math.round duke punuar). Kështu, qasja në window.Math do të ishte më e ngadaltë.
Gjithashtu, mënyra se si shihen variablat lart, do të shihni një rritje të performancës duke bërë var round = Math.round; dhe duke thirrur round(1.23), pasi të gjithë emrat shikohen fillimisht në shtrirjen aktuale lokale, pastaj shtrirjen mbi atë aktual, dhe kështu me radhë, gjatë gjithë rrugës. deri në shtrirjen globale. Çdo nivel shtrirjeje shton një kosto shumë të vogël.
Por përsëri, mos i bëni këto optimizime nëse nuk jeni të sigurt se do të bëjnë një ndryshim të dukshëm. Kodi i lexueshëm dhe i kuptueshëm është i rëndësishëm që ai të funksionojë ashtu siç duhet, tani dhe në të ardhmen.
Këtu është një profilim i plotë duke përdorur Firebug:
<!DOCTYPE html>
<html>
<head>
<title>Benchmark scope lookup</title>
</head>
<body>
<script>
function bench_window_Math_round() {
for (var i = 0; i < 100000; i++) {
window.Math.round(1.23);
}
}
function bench_Math_round() {
for (var i = 0; i < 100000; i++) {
Math.round(1.23);
}
}
function bench_round() {
for (var i = 0, round = Math.round; i < 100000; i++) {
round(1.23);
}
}
console.log('Profiling will begin in 3 seconds...');
setTimeout(function () {
console.profile();
for (var i = 0; i < 10; i++) {
bench_window_Math_round();
bench_Math_round();
bench_round();
}
console.profileEnd();
}, 3000);
</script>
</body>
</html>
Rezultatet e mia:
Time tregon totalin për 100,000 * 10 telefonata, Avg/Min/Max kohën e shfaqjes për 100,000 telefonata.
Calls Percent Own Time Time Avg Min Max
bench_window_Math_round
10 86.36% 1114.73ms 1114.73ms 111.473ms 110.827ms 114.018ms
bench_Math_round
10 8.21% 106.04ms 106.04ms 10.604ms 10.252ms 13.446ms
bench_round
10 5.43% 70.08ms 70.08ms 7.008ms 6.884ms 7.092ms
Siç mund ta shihni, window.Math është një ide vërtet e keqe. Mendoj se qasja në objektin global window shton shpenzime shtesë. Megjithatë, ndryshimi midis aksesimit të objektit Math nga shtrirja globale dhe thjesht aksesit të një ndryshoreje lokale me referencë në funksionin Math.round nuk është shumë i madh... Mbani në mend se kjo është 100,000 thirrje, dhe diferenca është vetëm 3.6 Znj. Edhe me një milion telefonata do të shihni vetëm një ndryshim prej 36 ms.
Gjërat për të menduar me kodin e mësipërm të profilizimit:
- Funksionet në fakt shikohen nga një fushë tjetër, e cila shton shpenzimet e përgjithshme (mezi vihet re, megjithatë, unë u përpoqa t'i importoja funksionet në funksionin anonim).
- Funksioni aktual
Math.round shton shpenzimet e larta (po hamendësoj rreth 6 ms në 100,000 thirrje).
23.01.2010
var sin = Math.sinshkaktoi një rënie të performancës. Ndoshta nuk njihet më si një funksion që zbatohet në x86 në mënyrë origjinale? 13.04.2013sinështë më i rëndë seround, kështu që ka të ngjarë që shpenzimi shumë i vogël i shkaktuar nga kërkimi shtesëMathështë aq i papërfillshëm sa nuk do të jeni në gjendje të matni ndryshimin midis rastësisë. Megjithatë, ekzekutimi aktual i funksionit nuk do të ndryshojë, pasi ka vetëm një zbatim. 16.04.2013Math.sin, Google për tabelën e kërkimit sinus. 16.04.2013