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.
Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
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.