Animatsiooniline veebiarendus: Jõudlus #2.2 – Firefox Performance tööriist

Animatsiooniline veebiarendus: Jõudlus #2.2 – Firefox Performance tööriist

Tänases Jõudluse osas võtame ette Firefoxi jõudluse tööriista.

Tegemist on põhimõtteliselt samasuguse tööriistaga nagu oli Performance Chromiumi tüüpi brauserites.

Eelmises osas tutvustasin ka jõudluse mõõtjat kui tööriista natukene üldisemalt (pärast lindistamise nippe läheb asi üle Chrome spetsiifiliseks). Soovitaksin seda soojalt lugeda.

Firefoxi jõudluse mõõtja

Firefox Perfomance tööriist

Ma soovitaks kasutada Firefox’i arendaja versiooni, sest tavalises firefox’is ei pruugi kõik funktsioonid/võimalused olemas olla.

Jällegi olen jaotanud jõudluse mõõtja neljaks osaks/paneeliks.

Esimene paneel on kontrollpaneel, millega saab performance tööriista kontrollida ja juhtida.

Kolm esimest nuppu esimesel paneelil on kõik seotud lindistamisega.

Kõige esimene nupp kustutab kõik laaditud lindistused. Teine nupp alustab uue lindistusega ja kolmandaga saab laadida salvestatud lindistused.

Lindistamine

Suure tõenäosusega sul pole sellist pilti ees nagu mul üleval on.

See on nii selletõttu, et sa pole veel (arvatavasti) lindistust teinud. Nüüd on aga aeg seda teha.

Ava mingi veebileht, kus tahad jõudlust analüüsida ning ava Firefoxi jõudluse mõõtja.

Jälgi kindlasti lindistamise nippe ja trikke, mida ma tutvustasin eelmises jõudluse osas.

Enne kui lindistama asud, soovitaksin ma vaadata esimese paneeli lõpus olevat hammasratast.

Seal saad kontrollida teatud aspekte lindistamisel või andmete näitamisel.

Kikka korra seda hammasratast ja kontrolli üle, et sul oleks lubatud “Record Allocations”. Teistest sättetest räägin ma hiljem.

Vajuta, kas esimesel paneelil olevat Record nuppu (vasakult teine) või neljanda paneeli keskel olevat “Start Recording Performance” nuppu.

Tee veebilehel vastavad toimingud ning lõpeta lindistamine, kas vajutades jälle ülevalt teist nuppu või neljanda paneeli “Stop Recording Performance” nuppu.

Nüüd peaks sul ees olema samasugune pilt nagu minul üleval.

Analüüsimine

Teise paneeli jätan ma praegu vahele, kuna see ei mängi suurt rolli ja liigun kolmanda paneeli juurde.

Kolmas paneel on põhimõtteliselt sama, mis Chromium tüüpi brauserites – see annab üldise pildi tehtud lindisusest.

Kõige üleval on millisekundid, nende all on üldkokkuvõte, millele brauser tol hetkel aega kulutas (need rohelised, lillad, punased, sinised kastid).

Need värvid tähistavad erinevaid asju:

  • Hall – teadmata tegevus
  • Lilla – asetuse arvutamine ja lisamine ehk kõik asetusega seotud
  • Roheline – värvimine ja kompositsioon
  • Heledam sinine – kompositiooni väljakutsumine (kuid mitte kompositsioon ise)
  • Oranž – DOMiga, HTMLiga, XMLiga ja JavaScriptiga seotud funktsioonid
  • Ere punane – DOMContentLoaded funktsioon
  • Ere sinine – Laadimine
  • Heledam punane – “Prügi” koristamisega seotud funktsioonid
  • Tumedam oranž – Tööline
  • Helesinine – konsooli funktsioon või timestamp (sellest allpool)

Kui soovid ise värvilegendi näha, siis vajuta esimesel paneelil lehtrikujulist ikooni just enne “Waterfall” vahelehte. Sealt saad ka valida, milliseid funktsioone ja toiminguid soovid analüüsiks kasutada.

Nende kastide all on omakorda tulpdiagramm, mida tegelikult võib pidada FPS mõõdikuks.

FPS määrab ära kui sujuvalt suutis brauser toimingut teha ehk kui suur oli kaadrisagedus tol hektel. Väga heaks FPSiks peetakse 60 kaadrit sekundis. Seega mida suurem tulp, seda parem.

FPS mõõdiku vasakus ääres on ka erinevad jooned, mis annavad aimu, milline madalaim, keskmine ja kõrgeim kaadrisagedus.

  • Roheline joon – kõrgeim FPS (60FPS)
  • Oranž joon – keskmine FPS
  • Punane – madalaim FPS

Mida rohkem lähemal on tulbad rohelisele joonele, seda parem.


Andmete edasiseks analüüsimiseks peaksime me sisse suumima, et saada paremat ülevaated mingist kindlast ajahetkest.

Sisse suumimiseks on Firefoxis põhiliselt üks võimalus – valides teiselt paneelilt mingi osa lindistusest.

Valimiseks tuleb minna hiirega teise paneeli peale; hoida hiire vasakut nuppu alla ja “lohistada” hiirt, kas vasakule või paremale.

Suumimine koos lohistamisega

Nüüd oled sa teatud ala välja valinud ehk sisse suuminud.

Teiseks võimaluseks saab valitud ala teha suuremaks või väiksemaks, muutes valitud ala piire.

Selleks tuleb hiirega minna suumitud osa äärmise pulga peale ja seda lohistada.

Suumimine koos äärmise pulkadega

Valitud ala saab ka liigutada ühest kohast teise (ilma piire muutmata).

Suumitud osa liigutamiseks mine hiirega valitud ala keskele ja lohista seda, kas paremale või vasakule.

Suumitud ala lohistamine

Välja suumimiseks lihtsalt klikka ühe korra kolmanda paneeli peal – nii näed kogu lindistust.


Liigume nüüd edasi põhipaneeli ehk neljanda paneeli juurde. Seal toimub suurem osa analüüsimisest.

Kindlasti märkasid sa, et kui sa suumisid sisse, siis muutus ka põhipaneel.

Neljas paneel sõltub tegelikult esimese paneeli vahelehtedest (need “Waterfall”, “Call Tree” jne).

Praegu on sul arvatavasti valitud “Waterfall” vaheleht – kui pole, siis vali see.

“Waterfall” vaheleht

“Waterfall” aitab sul defineerida, millele brauser kõige rohkem aega kulutab.

Nüüd mida ma soovitaksin “Waterfall” vahelehel kui ka analüüsimises üleüldse on valida kindel osa oma lindistusest välja, et seda paremini analüüsida.

Näiteks mina lindistasin nõnda, et ma teaksin, kus üks animatsioon lõpeb ja kus teine algab – pärast valisin ma ainult ühe animatsiooni, et seda analüüsida.

Nagu näed koosneb “Waterfall” vaheleht põhimõtteliselt samasugustest kastidest nagu esimesel paneelil, aga ainult nüüd on iga kast oma real.

Siin ka kehtib täpselt sama värvilegend ka.

Kui soovid teatud funktsioone või toiminguid mitte näha oma lindistuses, siis kasuta selleks esimesel paneelil olevat lehtrikujulust ikooni. Näiteks mina eemaldasin oma lindistusest kõik mitte visuaalsed funktsioonid, sest ma tean, et mul on probleem just visuaalidega.

Miks need kastid head on? Need on head, sest tänu nendele saad teada, mis üldist toimingut (värvimine, JavaScript jne) brauser tegi mingil ajahektel ja kui kaua ta seda tegi.

Nõnda saad ära defineerida, mis on sinu jõudluse alla tõmbajad.

Näiteks kui FPS on mõnes kohas madal, siis saad koheselt täpse ülevaate sellest, mida brauser tol hektel tegi – see on koht, kus arvatavasti pead koodi optimeerima.

Klikka mõne kasti rea peal ja sul peaks avanema paremal täpsem info selle toimingu kohta.

Waterfalli toimingu valik

Osadel toimingutel on olemas ka alamtoimingud – neid saab näha klikates toimingu vasakul pool oleval kolmnurgal.

Waterfall toimingu laiendamine

Nagu klipist näha võid, siis vahel näitab “Waterfall” ka JavaScripti Call Stack‘i (põhimõtteliselt funktsiooni side teiste funktsioonidega).

SIDENOTE: Olen siin ja eelmises õpetuses näiteks võtnud oma firma kodulehe AnsiVeeb.ee. Eelmises jõudluse postituses ütlesin, et minu ettevõtte veebileht on aeglane, sest see kasutab ära kõiki brauseri funktsioone, kuid mida ma olen ka märganud pärast natukene sügavamat analüüsi, et kõige rohkem kulub aega just kompositsioonile, mis on ka loogiline, sest AnsiVeebi kodulehel on kõik elemendid eraldi kihil.

“Waterfall” annab küll infot selle kohta, mida brauser mingil ajahetkel tegi (eriti siis kui on näha, kus jõudlus on alla käinud), kuid alati ei ole asi nii lihtne.

Esimene juhtum, kui “Waterfall” ei pruugi piisavalt andmeid anda on, siis kui JavaScript on põhiliseks jõudluse kitsaskohaks. “Waterfall” ei anna teada, millised funktsioonid tõmbavad jõudlust alla.

Teiseks juhtumiks võib pidada seda, kui FPS on pidevalt 40, kuid soov oleks see 60 peale saada ning ühtegi erilist jõudlust takistavat tegurit ei ole “Waterfallis” näha.

Nendeks toiminguteks tuleb meile appi “Call Tree”

“Call Tree” vaheleht

Suumi kindlasse animatsiooni/toimingusse sisse ja vali esimesel paneelil olev vaheleht “Call Tree”.

“Call Tree” annab sulle täpse ülevaate, millele brauser kõige rohkem aega kulutas.

Kui sul on jõudluse kitsaskohad seotud just JSiga, siis on sul kõige esimese reana olemas kindel JavaScripti funktsioon.

Kui aga sul on jõudluse kitsaskohad seotud graafikaga (nagu minul) või mõne muu brauseri sisefunktsiooniga, siis on sul täpse JavaScripti funktsiooni asemel vastav toiming (nagu näiteks “Graphics”, “Gecko” või mõni muu sarnane brauseri sisefunktsioon).

Nagu näed siis “Call Tree” koosneb erinevatest tupladest:

  • “Total Time” näitab kui kaua aega läks selle tegevuse ja teda väljakutsunud tegevuste peale kokku.
  • “Self Time” kuvab kui kaua aega läks just selle tegevusele peale.
  • “Samples” näitab brauseri “proove” ehk mitu korda tuvastas brauser, et seda funktsiooni või toimingut kutsuti välja (selle järgi on ka tulbad järjestatud).
  • “Total Cost” näitab protsendiliselt kui palju proove võttis see tegevus ja teda väljakutsunud tegevused enda alla võrreldes kogu Call Stack‘iga.
  • “Self Cost” kuvab protsendiliselt kui palju proove võttis see tegevus enda alla võrreldes kogu Call Stack‘iga.

Kui sa nüüd klikkaksid ühe funktsiooni kõrval olevale “kolmnurgale”, siis näed seda funktsiooni väljakutsunud funktsioone.

Vahete vahel võib näha (just väljakutsuvates funktsioonides), et “Self Cost” (või mõnu muu tabeli väärtus) on “0%”, kuid “Total Cost” on “1%” vms. See näitab, mis call stack‘i osast arvatavasti tuli “Self Cost” viimasesse, väljakutsutud funktsiooni.

Vaikimisi olekus on “Call Tree” nii-öelda pahupidi. See tähendab, et jõudluse mõõtja näitab sulle kõigepealt funktsiooni, mis võttis kõige rohkem aega, mis siis, et see sama funktsioon võib olla call stack‘i lõpus.

Kui sa millegipärast soovid, et jõudluse mõõtja näitaks sulle call stack‘i õiges järjekorras, siis klikka esimesel paneelil olevat hammasratast ja eemalda linnuke “Invert Call Tree” sätte eest selle peale klikates.

Nüüd näed call stack‘i õiges järjekorras, kuid mina soovitaksin hoida seda “pahupidi”, sest see annab sulle koheselt teada, millised toimingud võtavad kõige rohkem aega ja ressursse.

Minul on näiteks esimesel kohal Total Cost järgi Graphics (~50%), mis viitab just värvimis- ja visuaaltoimingutele. Järgneb Gecko (~40%), mis põhimõtteliselt on Firefoxi back-end ning Styles (~10%), mis viitab stiilide uuesti arvutamisele ja lisamisele. Ülejäänud toimingud on liiga väikesed, et neid siin nimetada.

Teine sätte, mis eemaldab “Call Tree” vahelehelt funktsioonide enda väljakutsumised (eesti keeles Rekursioon) on “Flatten Tree Recursion” – selle leiad ka esimese paneeli hammasratta alt. Kui sa arvad, et rekursioon on millegipärast sinu jõudluse kitsaskoht, siis eemalda linnuke antud sätte eest jälle klikates selle peal.

Jällegi ei pruugi “Call Tree” kõiki vajalikke ülesandeid täita, sest “Call Tree” annab meile küll informatsiooni, milline funktsioon oli kõige ajakulukam, kuid me ei tea seda, kas seda funktsiooni kutsuti välja mitu korda või see funktsioon võttis ise kaua aega.

Selleks tuleb meil kasutada “JS Flame Charti”.

Vaheleht “Flame Chart”

“Flame Chart” on mõeldud täielikult JavaScripti analüüsimisele.

Nagu ka ennist ütlesin, et “Flame Chart” annab meile teada, kas teatud funktsiooni kutsuti välja mitu korda või see funktsioon ise võttis kaua aega.

See on tähtis sellepärast, et kui jõudlus on halb ja teatud funktsioon on domineeriv “Call Tree” vahelehel, siis on kaks võimalust – kas selle funktsiooni koodi ise tuleb optimeerida (funktsioon võtab kaua aega) või tuleb optimeerida teist koodi, mis selle funktsiooni välja kutsub (et seda funktsiooni ei esineks liiga palju).

Loomulikult võib mõlemat teha, aga alati ei ole see ka võimalik.

Veel mida “Flame Chart” meile annab on terved Call Stack‘id (kui ka täiesti tavalised funktsioonid) ning millal antud toimingud täpselt toimusid.

Soovitavalt võiks Flame Chart vahelehel korralikult sisse suumida, sest muidu ei saa eriti hästi aru, mis mingil ajahetkel toimus.
“Flame Chartis” on võimalik ka sisse suumida kasutades kerimist (selleks tuleb hiirega olla neljanda paneeli peal) ning suumitud ala saab ka “Flame Chartis” hiirega liigutada/lohistada.

Näiteks minul on “Flame Chartis” näha, et ma kutsun välja pidevalt järjest välja värvimisega seotud toimingut (Graphics) – seega võib oletada, et see kood, mis kutsub välja Graphics toimingu, (ehk minu kood) ei ole optimeeritud, sest see kasutab liiga palju antud funktsiooni.

“Flame Chart” annab sulle ka JSi poolt kiiresti ülevaate, mis võivad olla sinu jõudluse kitsaskohad.

Näiteks kui mõne kohapeal on FPS madal, siis tuleb ainult minna “Flame Chart” vahelehel, sisse suumida ja juba näedki, mis funktsioon kitsaskoha põhjustas.

Nüüd ma tutvastaksin sulle kahte lisavõimalust Firefoxi jõudluse mõõtjas. Nimelt klikka jälle esimesel paneelil olevat hammasratast ja sealt omakorda klikka “Show Gecko Platform Data”.

Nüüd kindlasti märkasid, et kogu “Flame Chart” (kui ka “Call Tree”) läks äkki kirjuks. See juhtus sellepärast, et nüüd näed sa täpselt funktsioonide kaupa Gecko ehk Firefoxi tagaplaani toiminguid.

Vahetevahel võib see kasuks tulla – näiteks siis kui soovid teada, mida brauser ise täpselt tol hetkel tegi, kuid suure tõenäosusega sa seda tihti ei kasuta, sest tegemist on brauseri siseste toimingute, mida muuta pole erilist mõtet ning mis teeb ülejäänud analüüsimise päris raskeks.

Ma soovitaksin sul see maha võtta, aga nüüd sa vähemalt tead, mida see sätte teeb.

Kui sa “Show Gecko Platform Data” ära võtsid, siis kindlasti märkasid, et nende täpsete funktsioonide asemele tekkisid hoopis enne ka siin postituses mainitud üldistavad toimingud (nagu näiteks Graphics) – need annavad sulle üleüldse aimu, mida brauser tegi.

Teise võimalusena hammasratta all on meil “Invert Flame Chart”, mis põhimõtteliselt pöörab “Flame Chart” call stack‘i pahupidi ehk kõige viimased funktsioonid on kõige peal ja kõige esimesed kõige all.

Soovitavalt jätaksin mina selle välja, kuid ma arvan, et tegemist on rohkem maitse küsimusega.


Oleme läbi käinud kõik põhilised vahelehed, kuid veel on jäänud üks vaheleht – “Allocations”

Vaheleht “Allocations”

Kui sul ei ole vahelehte “Allocations”, siis ava esimese paneeli hammasratas ja luba “Record Allocations”. Nüüd tee uus lindistus ja sul peaks see vaheleht olemas olema.

“Allocations” ülesandeks on näidata, mis funktsioonid võtavad kõige rohkem mälu.

Iseenesest mälu tarbimine ei ole midagi hullu, sest JavaScriptil on olemas GC (Garbage Collection ehk “prügi väljaviimine”), mis vabastab automaatselt liigselt kasutuses oleva mälu, kuid probleeme jõudluses just tekitabki GC.

See tähendab, kui garbage collection toimub, siis meie lehekülje kiirus käib alla ja seda me tahame just vältida.

Selleks ongi meil vaheleht “Allocations”, et määrata ära mälu raiskavad funktsioonid ja neid optimeerida.

Kui sa lähed “Allocations” vahelehele, siis vaatab sulle otsa samalaadne tabel, mis “Call Trees”.

Kõik need tabelid tähendavad loomulikult eri asju:

  • “Self Count” näitab selle funktsiooni “mäluproove” ehk mitu korda brauser tuvastas, et see funktsioon kasutas mälu.
  • “Self Count (%P)” kuvab protsentides selle funktsiooni “mäluproove” võrreldes kogu call stack‘iga.
  • “Total Count” näitab selle ja teda väljakutsunud funktsioonide “mäluproove”.
  • “Total Count (%P)” kuvab protsentides selle ja teda väljakutsunud funktsioonide “mäluproove” võrreldes kogu call stack‘iga.
  • “Self Bytes” näitab kui palju baite võttis see funktsioon mälust (selle järgi on ka tulbad järjekorrastatud)
  • “Self Bytes (%P)” kuvab protsendiliselt kui palju baite võttis see funktsioon mälust võrreldes kogu call stack‘iga.
  • “Total Size” näitab kui palju võttis baite see funktsioon ja teda väljakutsunud funktsioonid kokku.
  • “Total Size (%P)” kuvab protsentides kui palju baite võttis see funktsioon ja teda väljakutsunud funktsioonid kokku võrreldes kogu call stack‘iga.

Kõige tähtsamad tulbad on arvatavasti siin “Self Bytes (%P)” ja “Total Size (%P)”, sest need näitavad, kui palju tarbiti mälu võrreldes kogu teiste funktsioonidega.

Loomulikult, kui kõik funktsioonid tarbivad palju mälu, siis pole nendest palju abi (siis navigeeri “Total Size” ja “Self Bytes” järgi), kuid tihtipeale viib jõudlust alla üks funktsioon.

Nagu ka “Call Trees” on siin call stack pahupidi ehk kõige rohkem mälu kasutanud funktsioonid on kõige peal ja nende all peidetult (klikka kolmnurka, et neid näha) on seda funktsiooni väljakutsunud funktsioonid.

Call Stacki näitamine

Kui soovid neid funktsioone millegipärast näha õiges järjekorras, siis klikka esimese paneeli hammasratal ja eemalda linnukene sätte “Invert Call Tree” eest.

Veel, mis on sarnane “Call Treega” on see, et siingi võib näiteks “Self Count” väärtuseks olla “0”, kuid “Total Count” on “1” vms. See tähendab jällegi seda, kust tuli see “mäluproov” viimasesse funktsiooni.

Nagu ennist ütlesin, et mälu kasutamine ei ole JavaScriptis probleem jõudluses, kuid probleemi tekitab just “prügi väljaviimine”.

Nimelt kui oled “Waterfall” vahelehel ja kui sul on olemas GC toimingud (punast värvid kastid) ning kui sa valid need, siis peaks sul avanema lisainformatsiooni veerg paremal.

Seal all on “Show allocations triggers”. Kui sellel klikkad, siis jõudluse tööriist valib just selle ala, mis põhjustas GCi ja näitab sulle vastavaid funktsioone.

Waterfall ja Allocations
Allikas: Firefoxi ametlik õpetus Allocations kohta

Ma ei lasku siinkohal prügi väljaviimise ja selle optimeerimise detailidesse, sest seegi õpetus on mul tulevikus plaanis teha, kuid kui kedagi huvitab, kuidas GCd optimeerida, siis siit saad lisainfot.

Lindistuse salvestamine ja importimine

Liigume nüüd tagasi teise paneeli juurde.

Sealt saad sa salvestada lindistusi.

Selleks vajuta valitud lindistuse juures olevat teksti “Save” ja salvesta see enda arvutisse.

Lindistuse importimiseks klikka esimesel paneelil olevat kolmandat, üleslaadimist kujutavat ikooni ja vali enda arvutist vastav lindistus.


Ongi Firefoxi jõudluse tööriist läbi võetud.

Kui sul tekkis küsimusi, siis küsi neid julgelt kommenteerides! 🙂


Senikaua ole tugev ja kohtume juba järgmistes postitustes,

Tähelepanu eest tänades – Oliver Paljak

P.S! Kui oled huvitatud animatsioonilisest veebilehest, siis võta minuga julgelt ühendust AnsiVeebi kodulehel.
Ma ei pea ennast praegu animatsioonilise veebiarenduse eksperdiks, kuid olen sellele spetsialiseerunud ja saan Sind väga palju aidata animatsioonilise veebilehe loomisel!

Leave a Reply

Your email address will not be published. Required fields are marked *