Le performance di JavaScript viste da Mozilla e dal team di IE 8

Le due novità di questi giorni in tema browser sono l’integrazione nel ramo di sviluppo principale di Firefox 3.1 di una nuova versione dell’interprete JavaScript, la cui particolarità è la presenza di un Just in Time Compiler, e l’altra è il rilascio della beta 2 di IE 8.

Le performance dell’interprete JavaScript che importanza hanno? Due approcci differenti: quello del team di Mozilla, che col rilascio di SpiderMonkey spinge in la il limite delle performance del linguaggio, e quello più conservativo di Microsoft, che sembra voler limitare i danni orientando i propri sforzi verso la “user experience”.

TraceMonkey…

Il nuovo interprete JavaScript di Firefox si chiama TraceMonkey e contiene un trace-based just-in-time compiler. Al contrario di SquirrelFish di WebKit, non viene generato un bytecode poi interpretato ma un codice binario eseguito direttamente dal processore. Al momento i back-end supportati sono x86, x86-64, e ARM. Prossimamente è previsto il supporto anche per PPC.

Un caratteristica di TraceMonkey è che la generazione del codice non avviene per metodo o classe, in base al numero di volte che vengono eseguiti, ma a partire da dei Trace Trees, alberi costruiti tracciando l’esecuzione del codice, che catturano i percorsi d’esecuzione più rilevanti, ad esempio i cicli, e che consentono al JIT compiler di tradurre solo il codice realmente eseguito.

Una descrizione più dettagliata dei Trace Trees si può trovare in uno articolo e in un documento che è possibile scaricare.

I Trace Trees sono nati per determinare l’esatto binding tra variabili e tipi di dato durate l’esecuzione in linguaggi dinamici come JavaScript, dove non c’è tipizzazione stretta. Questo di per se è già un’ottimizzazione rilevante, che applicata più genericamente ai linguaggi dinamici consentirebbe a questi di perdere lo svantaggio in termini di efficienza nei confronti dei linguaggi a tipizzazione forte. Se a questo si aggiunge la compilazione durante l’esecuzione, è facile immaginare che col tempo le capacità dei linguaggi come JavaScript possano raggiungere quelle di altri linguaggi più efficienti. In altri termini, per svolgere attività complesse sul browser non sarà più necessario affidarsi a linguaggi come il C e non sarà più necessario sviluppare plug-in. Certo, siamo ancora lontani dal raggiungere questo obiettivo, ma un ostacolo importante sembra sia stato rimosso.

IE 8…

IE 8 beta 2 è disponibile. Non poteva mancare la sequela di articoli pubblicati da IEBlog. In particolare mi ha incuriosito un articolo in tema di performance scritto da Christian Stockwell.

Secondo questo articolo, il team di IE 8 ha preferito alla ricerca delle performance pure su uno specifico componente, come l’interprete JavaScript, la selezione di aree di intervento stabilite in base ad una valutazione dell’impatto di ogni singolo componente del browser nel normale utilizzo. L’idea da cui nasce questo modo di procedere è che bisogna migliorare l’esperienza d’uso a beneficio dell’utente.

Un dato presentato è quanto i componenti incidano sulle performance del browser. Secondo una analisi condotta sulla beta 1 di IE 8, l’interprete JavaScript incide solo per il 3,23 sulla navigazione nei 100 siti più frequentati, per il 13,59% su siti che fanno uso intensivo di tecnologie AJAX. Da questo risultato ne consegue la necessità di distribuire l’impegno per l’ottimizzazione del browser, cioè di IE 8, su aree differenti.

Nella tabella seguente viene mostrato il tempo perso dalla CPU su ogni singolo componente.

Layout	Rendering	HTML Parsing	Marshalling	CSS Formatting	DOM	JScript	Other
8.87%	8.68%	1.48%	7.40%	36.72%	11.72%	13.59%	11.54%

Come si vede nella tabella, l’applicazione degli stili CSS, ancora più di JavaScript, del DOM e del pur rendering, è il punto su cui focalizzarsi nel tuning.

Nell’articolo si parla di un miglioramento delle performance del rendering engine rispetto a quelle non ottimali ottenute in modalità standard nella beta 1 di IE 8, peggiori di quelle di IE 7.

In generale l’articolo si concentra molto sul lavoro svolto dal teami di sviluppo di IE e tende a minimizzare i risultati ottenuti dalla concorrenza.

Certo, quando sei costretto ad inseguire, è difficile usare analoghi toni trionfalistici.

JavaScript…

L’attenzione che il team di IE pone sulla “browsing experience” è una scelta condivisibile. Tuttavia, mi pare che gli sviluppatori di Microsoft non abbiano compreso a fondo le implicazioni di un linguaggio che col passare del tempo viene usato per risolvere problemi sempre più complessi. Se in precedenza, a proposito delle scarse performance dell’interprete JavaScript di IE 7 e dei precessori, si era fatto presente che tale interprete era stato sviluppato in un momento in cui i compiti che avrebbe dovuto assolvere non erano di complessità paragonabile a quelli richiesti nell’era del Web2.0, oggi con le considerazioni fatte da Stockwell, non si fa alcun accenno ai problemi che potrebbe risolvere domani JavaScript.

Quali problemi risolvere allora?

Mike Schoepfer prova a darci un esempio. Ha realizzato una pagina in cui viene mostrata un’immagine di cui è possibile variare luminosità e contrasto tramite due slider.

Ho misurato la capacità dei diversi browser di eseguire rapidamente questo compito usando il pulsante “Animate” posto in basso nella pagina. Il risultato è un grafico che mostra il numero di trasformazioni per secondo eseguite dai vai browser.

Per eseguire il test è necessario un browser che supporti il tag canvas. IE 8 al momento non è in grado di eseguire il test.

Probabilmente questo non è il tipo di applicazione che beneficerà dell’incremento di prestazioni degli interpreti JavaScript. Mozilla ha investito molto su questo linguaggio, spingendosi ad utilizzarlo come linguaggio di sviluppo anche per le proprie applicazioni, che ricordiamo sono realizzate mettendo assieme componenti nativi, script javascript ed interfacce XUL. Un interprete più veloce può rendere l’applicazione più reattiva. Ma anche gli sviluppatori web, a partire da coloro che lavorano ai diversi framework nati per semplificare lo sviluppo di applicazioni web, potrebbero beneficiarne, magari spingendosi in la con la complessità delle funzionalità implementate.

SunSpider…

Per concludere, ho fatto l’ennesimo test con SunSpider, comparando i risultati ottenuti dai Webkit (build #35895), Minefield (Firefox 3.1a2), con e senza JIT attivato, e da IE 8 b2. Il grafico con i tempi di esecuzione dei test, espressi in millisecondi, è questo:

In questo test la differenza tra Firefox con JIT attivato e WebKit, che usa SquirrelFish, non è così marcata come con il demo dell’immagine.

---

Nella finestra di about è indicato: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080823021526 Minefield/3.1a2pre

Configurazione del test: MacBook Pro 2.4 Ghz Intel Core 2 Duo – 4 GB 667 Mhz DDR2 SDRAM – OS X 10.5.4 – Windows XP SP2 su Parallels Desktop