Szerző: Gálffy Csaba

2013. október 22. 10:55

Miért lassú a JavaScript mobilon?

Hosszas a szemétgyűjtés (garbage collection) előnyeinek és hátrányainak szakirodalma. Azonban míg a megoldás okos kompromisszumnak számít PC-n és szerveren, a mobilos felhasználásnak kemény korlátjai vannak. Megoldások léteznek, de nem egyszerűek.

A webes alkalmazások egyik nagy problémája jelenleg a JavaScript viszonylagos lassúsága. Ugyan a nyelv egyes alapvető feladatokra kiválóan alkalmas (például statikus felületek összerakására), komplexebb webes alkalmazásokhoz és különösen animációkhoz alkalmatlan. Ennek oka, hogy a nyelv agresszív szemétgyűjtő algoritmusa (garbage collection) kvázi véletlenszerű időpontokban fut le, ilyenkor pedig a teljes app futása megáll századmásodpercekre, de néha tizedmásodpercekre is. Ez nagyon látványos akadozáshoz vezet, ami gyenge felhasználói élményt eredményez. A helyzeten az elmúlt néhány évben sokat javított az új generációs JavaScript-motorok (Google V8, Apple Nitro, Mozilla xMonkey) használata, az elmúlt időszakban azonban a fejlődés lelassult, amelyet a hardveres előrelépés sem tudott újra bepörgetni.

Memóriaprobléma a köbön

A garbage collectiont használó nyelvek (JavaScript, Java, C#, stb.) asztali és szerveres környezetben kiválóan használhatóak és viszonylag gyorsak - mobilon azonban nem ilyen rózsás a helyzet. Ennek oka, hogy az alkalmazás rendelkezésére álló memória sokkal kisebb mint PC-s vagy szerveres környezetben, a processzor teljesítményének dinamikus tartománya pedig sokkal szűkebb, a maximális teljesítmény jóval alacsonyabb. Egy sokszor hivatkozott kutatás szerint a GC által okozott sebességproblémák a memória mennyiségének csökkenésével drámaian megnövekednek.

A problémát jól illusztrálja a Google saját JavaScript tesztje, amely a GC által okozott akadozást hivatott szemléltetni. Míg PC-n a lag-csúcsok jellemzően a néhány századmásodperces kategóriában maradnak és nem mennek tizedmásodperces tartományba, mobilon (HTC One/Chrome) sűrűn vannak több tizedmásodperces akadások is. A CPU teljesítménye egyébként mobilon sem kicsi, ahogy ezt egyéb tesztek már jól mutatják, a GC által okozott akadozást azonban ez sem tudja kiküszöbölni.

A JavaScript memóriakezelési problémáin a lokális változók globális használatát lehetővé tévő closure-ök használata sem segít. A megközelítést számos népszerű JavaScript framework használja, például a jQuery is. A closure használata ugyan sok tekintetben nagyon megkönnyíti a programozó munkáját, az alkalmazás memóriahasználatát azonban kiszámíthatatlanná, a szemétgyűjtést nehézkessé teszi, ami tovább rontja az ilyen alkalmazás teljesítményét.

Használjunk köztesréteget?

A JavaScript teljesítményproblémáival a Google is maximálisan tisztában van. Nem csoda, a cég a Chrome böngésző fejlesztését pontosan azért kezdte el, mert elégedetlen volt az Internet Explorer és a Firefox JavaScript-motorjának teljesítményével. A szemétgyűjtés által okozott lag problémájára azonban a Google-nek sincs csodafegyvere, az egyetlen jó megoldás, ha az automatikus memóriakezelés helyett minél inkább saját kézbe vesszük azt és olyan keretrendszert/köztesréteget használunk, amely ezt elvégzi. Az Emscripten például egy ilyen fordító, amely C/C++ kódból állít elő memóriahasználatra optimalizált JavaScriptet, a memóriakezelést pedig kiveszi a JS-motor kezéből és az alkalmazásnál tartja. Az eredmény sokkal folyamatosabb futás és az olyan fejlett, GC nélküli JavaScript-technológiák, mint a Mozilla-féle asm.js megszületése.

Mindent vivő munkahelyek

Mindig voltak olyan informatikai munkahelyek, melyek nagyon jól fekszenek az önéletrajzban.

Mindent vivő munkahelyek Mindig voltak olyan informatikai munkahelyek, melyek nagyon jól fekszenek az önéletrajzban.

A JavaScript-kérdés megoldására nem csak a Google és a Mozilla ugrott rá, a Microsoft a TypeScripttel szintén hasonló célokat tűzött ki maga elé. A C# fejlesztési vezetőjének, Anders Hejlsbergnek a szárnyai alatt fejlődő projekt a nagy kódbázissal rendelkező webes alkalmazások fejlesztését könnyítené meg, a típusok bevezetésével és az objektumorientált megközelítéssel. A TypeScript (a Google Darthoz és a Mozilla asm.js-hez hasonlóan) a kódból végül szabványos JavaScriptet állít elő, amely minden böngészővel kompatibilis, a fejlesztés könnyebb, a teljesítmény pedig magasabb, mint a kézzel írt JS.

Egyes szereplők szerint ugyanakkor a jól megírt JavaScript teljesítménye is elviselhető tud lenni. Amikor a Facebook bejelentette, hogy befejezi HTML5/JavaScript alapokon nyugvó alkalmazásának fejlesztését és teljesen natív appot ír Androidra és iOS-re, sokan a Fastbook nevű klónra mutogattak, amely sikerrel oldotta meg a gyors JS kérdését, és a DOM-csomók agresszív újrahasznosításával elkerülte a GC okozta teljesítményproblémát. Az ilyen innovatív megközelítések miatt továbbra is van persze helye a JavaScriptnek mobilon, a legtöbb fejlesztő számára ez kényelmesebben elérhető a köztesrétegeken keresztül.

A probléma megoldásában segít a GPU-alapú feldolgozás előretörése is. Colt McAnlis a héten tartott O'Reilly Velocity konferencián tartott előadása jól összefoglalja, hogy a GPU-alapú weboldal-renderelés milyen előnyöket hoz, a feldolgozás egyes elemeire kiválóan használható a grafikus processzor ereje - ehhez azonban megint olyan weboldalak tervezésére van szükség, amelyek kihasználják (vagy legalábbis lehetővé teszik) ezt a fajta gyorsítást.

Kubernetes képzéseinket már közel 300 szakember végezte el. A nagy sikerre való tekintettel a tanfolyamot aktualizált tananyaggal június 18-án újra elindítjuk! A 8 alkalmas, élő képzés képzés órái utólag is visszanézhetők, és munkaidő végén kezdődnek.

a címlapról

FLIP

3

Kagylómobillal erősít a Honor

2024. június 14. 10:28

A cég útnak indította első flip típusú készülékét, amivel újabb hézagot foltoz be a nagy márkák elleni versenyben.