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

JBoss: nuova jBPM Console e altro…

C’entra sempre GWT.

The new BPM console approaches it’s first milestone and I’d like to use that opportunity to introduce you to the most important changes and new features.

Moving to GWT
More and more JBoss projects are moving to GWT. And they do it for a good reason:

• If you are familiar with Java development and don’t want to become the next web developer expert, then GWT is a good choice. With GWT you can stick to eclipse, fire up a debugger and write unit tests.
• It has a rich set of UI widgets that you can use out of the box. The widgets also force a common look and feel across implementations.

Another good example of a successful GWT implementation is the Drools console.

Dagli screen shot sembra che abbiano usato GWT Ext.

Quand’è che toccherà a Wise?

Per la notizia: http://www.jboss.org/feeds/post/first_glimpse_at_the_new_bpm_console

Secret-switch

Visto che immancabilmente una cosa del genere viene tirata in ballo, è il caso di citare un post che tenta di chiarire cosa fa il killswitch:

http://www.zdziarski.com/papers/killswitch.html

Dal punto di vista pragmatico, non penso che un meccanismo del genere si assolutamente inutile. Il problema è che il suo uso deve avere il consenso dell’utente. Cioè, io mi affido ad Apple affinché questa allerti il mio iPhone circa l’esistenza di applicazioni potenzialmente dannose. Però Apple deve quantomeno mettermi a conoscenza di questo fatto. Il dubbio scontanto è che mantenendo la segretezza in realtà si voglia nascondere qualche uso discutibile del meccanismo. Però a mio avviso questo è più un problema di immagine: non si può esprimere una condanna in assenza di un corrispondente misfatto, però se ti comporti in modo che si fa credere alla gente che vuoi fare qualcosa… se scappi appena vedi degli agenti di polizia, probabilmente quelli ti inseguono, anche se tu non hai fatto nulla

Io ho un’idea relativa a questi ed altri comportamenti “strani” di Apple. Hanno la fissa della segretezza. Sembra una fesseria. Provate ad andare ad un evento per sviluppatori con registrazione libera. La firma del NDA è obbligatoria, anche quando si sa che tanto quelle informazioni circoleranno e ti rendi conto che i dettagli che ti trasferiscono sembrano tutto fuorché che informazioni da tenere assolutamente riservate, e magari gioverebbe di più trasferirle al maggior numero di interessati. Se sei un blogger che osa pubblicare una indiscrezione, ti trovi i loro avvocati addosso…

Questo è un punto su cui potrebbero migliorare tantissimo.

P.S.: Se vi interessa questa “black-list”, l’url è https://iphone-services.apple.com/clbl/unauthorizedApps

La Baia

È inutile dire, che c’è chi per lavoro sembra fare il burocrate che si preoccupa di capire se le proprie azioni hanno un senso. La realtà dimostra che le loro azioni non servono a nulla, se non a fare un po’ di rumore.

Io è da un anno e più che uso OpenDNS. Per cui quando la magistratura si è premurata di oscurare The Pirate Bay e FastWeb, il mio ISP, ha provveduto ad eseguire, io manco me ne sono accorto. Gli svedesi malefici si sono affrettati a cambiare indirizzo IP, ad aprire un nuovo dominio, labaia.org, e a consigliare a tutti gli italiani di usare OpenDNS.

Ma poi, con tutti i meta-motori di ricerca, ci si deve preoccupare di un sito che sparisce?

Non so che dire… infatti non parlo… è tardi… uno sbadiglio… in lontananza odo l’eco di una pernacchia. È meritata.

GWT – qualche suggerimento (2)

Un suggerimento che ho trovato in rete è di sviluppare usando solo una locale e definendo un browser di test. Poiché, come abbiamo detto, GWT crea una versione compilata per ogni browser supportato e per ogni locale, basta definire nel file di definizione del modulo una sola locale ed impostare il browser supportato. Cioè, le righe relative alle altre locale vanno commentate:

<extend-property name=”locale” values=”it” />
<!–
<extend-property name=”locale” values=”de_DE” />
<extend-property name=”locale” values=”en_UK” />
<extend-property name=”locale” values=”fr_FR” />
–>

E in più bisogna specificare lo user agent, cioè il browser, per cui si intende compilare:

<set-property name=”user.agent” value=”gecko1_8″ />

Il valore specificato cambia a seconda del sistema operativo su cui si sviluppa. Cioè, “gecko1_8″ va bene su linux, mentre su windows bisogna usare “ie6″ e su OS X “safari”.

Una volta terminato lo sviluppo, bisogna ricordarsi di ripristinare le locale rimosse e togliere l’indicazione del browser, in modo che rilasciando l’applicazione chiunque possa usarla. A tal proposito, penso sia utile definire due file .gwt.xml. Cio, se il file del modulo è

Module.gwt.xml

A questo dovrebbe essere affiancato un

ModuleDev.gwt.xml

Se il build.xml ha un task per la compilazione dei sorgenti GWT, il primo modulo va usato in questo task. Il secondo può essere usato nelle run configuration aggiunte nella copia locale del progetto per lanciare localmente l’interfaccia. Tral’altro, questa soluzione da la possibilità di definire servlet differenti per i servizi quando l’applicazione viene rilasciata e quando viene testata localmente. Uno dei problemi riscontrati lavorando con GWT è che non è sempre possibile usare l’hosted mode se il codice server-side per essere eseguito richiede un container con requisiti diversi da quelli supportati dal Tomcat distribuito con GWT.

GWT – qualche suggerimento

Dopo un po di lavoro fatto e qualche articolo letto in proposito, posso incominciare a dare qualche suggerimento.

La prima cosa che ho potuto notare è che passando dalla versione 1.4 alla 1.5 di GWT i tempi di compilazione si sono parecchio allungati. In più leggendo in rete in proposito nei diversi blog su GWT, sembra che questi tempi dipendano anche da quanto viene usato il meccanismo di defered binding. Cioè, ogni versione di codice generato, ad esempio ogni locale, richiede una compilazione specifica. Comunque, non ho ancora potuto constatare quanto sia rilevante il peso del defered binding durante la compilazione.

Un altro problema, con cui per il momento non ho avuto a che fare ma che altri utilizzatori di GWT hanno potuto constatare, è che i moduli particolarmente complessi impiegano tempo ad esser caricati ed avviati dal browser. Quindi, attenzione ai tempi di avvio dei moduli soprattutto con i browser che hanno un interprete javascript particolarmente lento (IE su tutti).

Altro consiglio: non vi fidate di quello che vedete su un browser. Per quanto GWT faccia un ottimo lavoro nel nascondere le differenze tra i vari browser, non è certo che lo riesca a fare in ogni caso.

Soluzioni?

Suddividere l’applicazione in più moduli, se possibile. Suddividere la compilazione in più moduli (devo ancora mettere in pratica quest’ultima soluzione per sperimentarne la sua efficacia). Sperare che gli sviluppatori di GWT implementino al più presto il lazy loading (suddivisione del codice javascript in più file scaricati dal browser su richiesta, cioè quando la specifica funzionalità è utilizzata), cosa prevista dalla roadmap. Usate diversi browser per testare la vostra applicazione.

Una scoperta riguarda il codice compilato. Intanto non è così criptico come sembra. La prima cosa che ho capito è che i metodi sono tradotti in funzioni con un primo parametro che è l’oggetto il cui metodo è chiamato, con gli altri parametri di seguito. Il codice generato corrisponde grosso modo a quello scritto in java. In più, è possibile istruire il compilatore GWT per fargli generare codice leggibile (o quasi). Tutto questo può essere utile nel caso in cui non possiate verificare il vostro codice eseguendo l’applicazione in hosted mode.