Overclock css-szelektor id ellen osztály, második forduló
Overclock CSS-választókat: id ellen osztály, második forduló
Az első cikk ebben a sorozatban, figyelembe vettem a sebességet a motor kialakulásáért felelős és megjelenítését HTML-oldalak a képernyőn. Most azonban, mi fog összpontosítani egy kicsit más szempont, mint a motor CSS-választókat. Ezt a tesztsorozatot szenteltek gyorsítsa létrehozását egy külön HTML-dokumentumot.
Ha az első két tanulmány megkérdőjelezte böngésző felismerési arány CSS-szabályok és azok alkalmazása, most érdekel egy másik kérdés, nevezetesen: milyen gyorsan a böngésző létrehoz egy DOM-fa, attól függően, hogy az elemek jelenlétét egy id vagy osztály?
Erre a célra készült 3 készlet HTML-fájlokat. Az első tartalmazta a 10.000 elemeket, amelyek rész azonosítója (száma elemzi elemek változtattuk 50 és 10000). A második HTML-fájlok gyakorlatilag azonosak voltak, csak ahelyett, id van az attribútum osztály. A harmadik készletben csak elemeinek ID (azaz, változatos elemek száma is) a DOM-fa. Ennek megfelelően a méréseket egy rejtett iframe. Kerülendő teszi a letöltött weboldal a képernyőn.
Ahhoz, hogy mérni az időt, hogy hozzon létre oldalon ugyanazt a jól bevált, a technológia, hogy a korábbi vizsgálatok: ő volt az ideje, hogy jelölje meg egy sor elemet, majd állítsa be, majd kivonjuk az utolsó. Végleges eredmények súlyozott átlagok különböző böngészők között.
Hatás a getElementById
Továbbá, a HTML-fájlokat tartalmazó azonosítók, fuss számítások getElementById (id1) 10000-szerese (annak érdekében, hogy ellenőrizze, hogy a tételek száma, illetve azonosítók által érintett eljárás). Az eredmény nagyon érdekes, de nagyon nehéz előre megjósolni. Talán ezekben a vizsgálatokban, ez a szempont a böngésző fogja vizsgálni részletesebben.
A vizsgálatokat maguk is vezetni webo.in/tests/css-efficiency-3/ vagy letölthető az oldalon minden egy archív (együtt én eredmények).
Mindhárom vizsgálati készletek (egyenként 6 fájl, voltak 50, 100, 500, 1000, 5000 és 10000 vizsgált elemek) futtatunk 10-szer 5 böngészők (Firefox2, IE6, IE7, opera 9,5 (igen, nem kéne 9,27), és a Safari 3). Ennek eredményeként, a hiba csökkent statisztikai módszerekkel, hogy a megengedett értéket: 2-3%.
Csak szeretnék megemlíteni egy enyhe kiugrás a legelső dokumentum minden böngészőben: a legvalószínűbb, ha a dokumentum betöltése egy iframe-böngésző (ez volt a jellemző, hogy az egész világ) kiosztja egy bizonyos mennyiségű memóriát az új HTML-dokumentumot az iframe. amely azután bármilyen módon, hogy újra használható az új dokumentumokat. Ennek eredményeként, a dokumentum azonosítókat 50 10000 sejt eredmények kicsit rossz.
Talán a jövőben ez a szempont érdemes figyelembe venni, és töltsön be egy üres dokumentumot az elején, vagy még jobb, töltse le a dokumentumot a maximális objektumok száma a memóriát nem befolyásolja a későbbi mérés. Ugyanakkor a kvalitatív következtetéseket, ez az eltérés nem befolyásolja.
találatok
Talán a legegyszerűbb módja az lenne, hogy ismertesse az eredményeket például grafikonok, hogy elvileg lesz. Néhány szó a legenda: a begyűjtött 5 esetben. ID (create) tükrözi a létrehozása HTML-dokumentum 10.000 elemek (div), amelynek mindössze 50-ban 10000 azonosítókat. osztály (create) megfelel annak az időnek a teremtés ugyanazt a dokumentumot, hanem az osztály id. ID (tiszta) jellemzi az idő a dokumentum létrehozásához, amelyben az összes elem van azonosítók (de az összes elemek voltak 50 10000). Két táblázat 10.000 kap időt mutatják átvételekor a tételt egy egyedi azonosítóval, 10.000-szer az első és a harmadik dokumentum, ill.
1. ábra: A sebesség a dokumentum létrehozása és visszakeresés eleme a Firefox 2-
2. ábra A sebesség a dokumentum létrehozása és visszakereső tag IE 6
3. ábra A sebesség a dokumentum létrehozása és visszakereső tag IE 7
4. ábra: A sebesség a dokumentum létrehozása és visszakeresés elem Opera 9.5
5. ábra A sebesség a dokumentum létrehozása és visszakereső elem a Safari 3
Az Internet Explorer nehéz megérteni valamit, mert ideje számítani az elem azonosító érdekében valamivel kisebb, mint az idő, a dokumentum létrehozásához, ennek eredményeként, hogy „elfelejti” az összes találatot. Alul vannak elválasztva grafikákat súlyozott átlagos értéke (természetesen a fő szerepe van az Internet Explorer).
6. ábra: A sebesség a dokumentum létrehozása, súlyozott átlaga az összes böngésző
7. ábra: A mintavételezési sebesség elemet, súlyozott minden böngésző
A grafikon az átlagos értékek egyértelműen látható, hogy, ceteris paribus, a dokumentum létrehozása vérrel osztályú kevesebbe kerül, mint ID (általában 2-től 10% nyeremény). Ha figyelembe vesszük, hogy element.class -selector dolgozzanak ki gyorsabban #id ugyanabban az 10% -ot, a teljes győzelem, ha a dokumentum azonosítókat előtt osztályok lesz mintegy 15%. Abszolút értelemben, ezek a számok nem túl nagy: a Centrino Duo 1.7 fordul egy szám körülbelül 0,0085ms 1 ID (átlagosan 3 CSS-szabályok és a használatát 1).
Azonban (szükség szerint, általában), jelentős terhet pontosan létre a DOM-fa a dokumentum (láthatja, hogy az exponenciálisan növekvő ideje Opera, Firefox és a Safari), és maga a dokumentum (konstans idő 60ms IE, ami felülmúlja az összes a többi rezsi létrehozásának közepén egy dokumentum). Általában ezek a műveletek megy 70% -át az idő (azaz a legnagyobb megtakarítást lehet elérni méretét minimalizáljuk a fa, és a szám a HTML-oldalak töltik, például egy keret, azt tervezik, hogy végezzen további kutatást ezen a területen).
A számítás az azonosító egy elem, furcsa módon, a legnagyobb hatást ismét DOM-fát, mint ahány ilyen elemek. Még 1000 elemek az id több mint a fele az idő költségek vissza lehet vágni, ha csak számának csökkentése elemek (különösen észrevehető IE).
Általában alapvető tipp míg két: csökkenti a DOM-fa-id, és csak a valóban szükséges esetben.