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.

Aggiornamento performance JS

Visto che è stata rilasciata la nuova beta di Firefox 3.0, ho aggiornato il grafico comparativo dei risultati ottenuti col test SunSpider.

Notare i risultati ottenuti da FireFox dopo le ottimizzazioni della patch PGO.

Explorer 8? Mi serve una nuova macchina virtuale…

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.

Quando arriva IE 8?

Me lo chiedo perché vorrei non dovermi più preoccupare di certi problemi.

So bene che la perfezione è un’utopia, ma la situazione potrebbe essere decisamente migliore a quella attuale.

Perché mi lamento? Dunque… argomento: visual formatting model – attributo display.Il w3c dice a proposito dell’attributo display:

“inline-block

This value causes an element to generate a block box, which itself is flowed as a single inline box, similar to a replaced element. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an inline replaced element”.

Firefox 2 implementa in modo errato questa modalità. Stiamo calmi! Per fortuna, questo bug è stato corretto in Firefox 3. Opera e Safari… pardon, WebKit (io preferisco le nightly build) non danno problemi. IE 7 si mostra in teoria capace di implementare questa modalità; con display: inline e width e height specificati renderizza il blocco come previsto dallo standard nel per display: inline-block. Eppure display: inline-block sembra proprio non sappia cosa sia. E non mi pare neanche che un suo eventuale supporto avrebbe prodotto chissà quali problemi.

Siamo buoni: se ne sono dimenticati.

Altra dimenticanza: empty-cells: show. Ovvero, dobbiamo continuare a complicare il nostro codice inutilmente per produrre inutili. Ma era così difficile da realizzare?