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

Nuovi risultati dal test SunSpider

Dato che sono stati rilasciati Safari 3.1 e Explorer 8 beta ho aggiornato il tabellone con i risultati ottenuti dai vari browser nel test SunSpider. Il grafico sotto riguarda il test eseguito sulle ultime versioni dei diversi browser. Opera 9.5 beta è escluso perché non completa il test (i valori parziali ottenuti indicano un probabile incremento di prestazioni che va dal 30 al 50% a seconda dei casi).

Si possono notare il primato di Safari 3.1, anche rispetto alla nightly build di WebKit, e l’ottimo risultato ottenuto da IE 8 beta.

Adesso la competizione è più serrata.

Performance di JScript

Dopo il rilascio di SunSpider, la suite di benchmark realizzata dagli sviluppatori del WebKit, avevo fatto dei test sulla mia macchina, confrontando tra di loro diversi browser, IE incluso testato su una macchina virtuale. I risultati sono riassunti in questo grafico(*):

Il test SunSpider misura le prestazioni dell’interprete javascript di per se, quindi senza prendere in considerazione funzionalità più specifiche del browser come l’implementazione di DOM e le api javascript del browser.

Mi avevano colpito due dati. Il primo è l’incremento di prestazioni riscontrabile nelle nightly build del WebKit rispetto a quelle espresse da Safari (ora uso queste al posto di Safari). Il secondo è lo scarso risultato ottenuto da IE 7 sui test che si basano sulla manipolazione delle stringhe. Certo, si parla di un test eseguito usando una macchina virtuale, ma questo non può mettere in secondo piano il fatto che gli altri test non producono numeri così insoddisfacenti.

Qualche giorno fa ho trovato un post interessante sul blog di JScript in cui si parla dell’implementazione non ottimale dell’operatore + applicato sulle stringhe. In pratica, l’operazione di concatenazione, che comporta la creazione di un buffer in grado di contenere il risultato e la copia del contenuto dei due operandi, viene eseguita ogni volta che si presenta l’operatore +. Nel caso di concatenazioni multiple, non è prevista alcuna ottimizzazione per evitare di ripetere più volte inutili operazioni di allocazione e copia di buffer.Non so quanto questo c’entri con i risultati di sopra.

Nell’articolo mi colpisce una frase: “Jscript was meant to be used just as glue, not as full-fledge programming language as used in modern WebApps“.In un altro articolo a proposito delle prestazioni del garbage collector di JScript leggo qualcosa di simile: “the JScript GC was designed for simple little web pages“.

In effetti JScript come lo conosciamo ora è nato anni or sono quando non si prevedevano certe evoluzioni del web, con la proliferazione di applicazioni web di una certa complessità e dei vari toolkit javascript nati per renderne più semplice lo sviluppo e per spingere oltre il livello di complessità.

(*) Le specifiche della macchina sono le seguenti: MacBook, processore Intel Core 2 Duo 1.83 GHz, Cache L2 2 MB, 2 GB ram,  bus 667 MHz, Mac OS X 10.5.1 (9B18); per Explorer ho usato Windows XP Sp2 su Parallels desktop con assegnati 1GB di ram e configurato per ottimizzare le prestazioni della macchina virtuale.