Így csökkentette a Chrome memóriafogyasztását a Google

Jelentős optimalizációt kapott a Chrome alatt dolgozó JavaScript-motor, a V8. A fejlesztők jelentősen visszafogták a memóriahasználatot, mind a V8 saját belső működését, mind a futtatott JavaScript programok végrehajtását illetően. Lássuk a részleteket.

Kapacitásfüggő viselkedés

Az optimalizálás egy bizonyos ponton túl kompromisszumokat jelent, az egyik jellemző már nem javítható anélkül, hogy egy másik területen ne legyen némi visszaesés. Esetünkben attól függően, hogy mekkora memória van a telefonban, egészen eltérő lehet az ideális viselkedés: a szemétgyűjtésre (a memória felszabadítására) például nagyobb kapacitás mellett ritkán kell sort keríteni, ez jó, mert ez egy pillanatra megakasztja a felhasználói felületet is, ami csorbítja a felhasználói élményt. Azonban nagyon kis memóriával szerelt eszközöknél mégis kívánatos a gyakori szemétgyűjtés (GC), mert ennek alternatívája még rosszabb, kifut memóriából a program és kilép, vagy felfüggeszti a tabok működését.

^{Memóriahasználat az 53-as Chrome-hoz viszonyítva kis kapacitású eszközökön.}

Ezért az ilyen kis kapacitású eszközökhöz a Chrome egy speciális módot használ, amely több ponton is módosítja a szemétgyűjtési algoritmust. Egyrészt a GC lényegesen gyakrabban fut le és sokkal jobban vigyáz a töredezettség elkerülésére, illetve sokkal szigorúbban kezeli a tervezett memóriafoglalási kvóták túllépését. Ezek a lépések együtt látványosan visszafogják a Chrome memóriahasználatát - igaz, kompromisszumos megoldásként viszont szerényebb felhasználói élményt is hoznak.

Ehhez kapcsolódik, hogy a V8 heap page méretét 1 megabájtról 512 kilobájtra csökkentette a csapat, ennek akkor van jelentősége, ha az élő objektumok száma viszonylag kevés - emellett pedig a memóriafragmentációt is felére vágja. Ez a változtatás az asztali gépeknél és notebookoknál is éreztetni fogja pozitív hatását.

Zónázó memóriakezelés

A V8 motor saját belső működéséhez úgynevezett memóriazónákat használ. Ezek olyan memóriarégiók, amelyek az összetartozó objektumokat tárolják, egy lépésben allokálhatóak és törölhetőek, ha szükségtelenné válnak. Ilyen zónákat széles körben használ a V8 a parser és a fordító oldalán is, ahol az egyes tevékenységek végrehajtása után jól jön, hogy a memóriaterület egyben felszabadítható.

Ehhez kapcsolódik az egyik fontosabb optimalizáció: a memóriahasználat vizualizálásával derült ki, hogy a V8 egyik komponense, a háttérparser (amely az oldal betöltődése során dolgozza fel a JavaScript kódot) életben tart egy memóriazónát jóval azután is, hogy arra szükség lenne. Triviális megoldás a hiba javítása, a tevékenység végeztével a zóna felszabadul, ezzel csökken a memóriahasználat.

^{Memóriahasználat asztali gépen.}

Égbe révedő informatikusok: az Időkép-sztori Mi fán terem az előrejelzés, hogy milyen infrastruktúra dolgozik az Időkép alatt, mi várható a deep learning modellek térnyerésével?

Egy másik optimalizáció a C fordító munkájához kapcsolódik. Az absztrakt szintaxisfa (AST) egyes elemeinek hatékony tárolását normál esetben a C fordító végzi. A Google példája: két boolean típusú változó tárolása két bitet igényel, így egy word objektumban (vagy egy előző word megmaradt részében) eltárolható. A mérnökök azt találták azonban, hogy a felhasznált C fordító nem túl okos a leghatékonyabb tárolási módszerek megtalálásában, így a biteket érdemes inkább manuálisan csomagolgatni. Ez számottevően tudja csökkenteni a memóriahasználatot, és mintegy mellékhatásként a parser és a fordító teljesítménye is emelkedik - mondja a bejegyzés.

Optimalizáláshoz mérés kell

Teljesítmény (vagy épp memóriahasználat) optimalizálásához mérések is kellenek, hogy a különböző módosítások hatását kvantifikálni lehessen, az alternatív megoldások közül pedig ki lehessen választani a legjobbat. Ezek a döntések azonban csak adatok birtokában hozhatóak meg, így válnak összemérhetővé a hatások. A fenti optimalizációhoz a Google a Telemetryt használta, amely képes rögzíteni majd konzisztensen visszajátszani bizonyos felhasználói forgatókönyveket.

A másik, egyedi fejlesztésű eszköz a memóriahasználat vizualizációját segíti. A rendkívül komplex memóriakezelést ezzel valamennyire átláthatóvá lehet tenni, nem véletlen, hogy nagy szerepet játszott az optimalizációban. A kis eszköz képes a különböző adatstruktúrákat megjeleníteni, a memóriahelyek pedig akár egyes kódrészletekhez visszakövethetőek, így gyorsan ellenőrizhető, hogy a program viselkedése megfelel-e a tervezettnek, vagy van valamilyen eltérés (mint a háttérparser fenti esetében).

Az eredmények magukért beszélnek: a fejlesztők saját mérései szerint a kis memóriakapacitású eszközöknél 35 százalékkal csökkent a Chrome memóriahasználata, de a többi eszköztípusnál is érezhetően csökkent ez a mutató. A következő lépésben egyébként a fejlesztők a fél gigabájt és 1 gigabájt közötti memóriával szerelt eszközöket célozzák, ezek kapnak majd egyedi GC-heurisztikát, ami a jelenleginél jobb felhasználói élményt ígér.