Un confronto sul consumo della memoria

Ho fatto dei testo sull’occupazione della memoria dei tre browser per OS X. Il test è stato eseguito all’avvio del browser e su tre diverse pagine:

Il test per ogni browser è stato eseguito nel seguente modo: browser chiuso e riaperto, quindi eseguita misura oppure incollata url della pagina di test ed eseguita misura; in ogni caso la memoria reale indicata nell’Activity Monitor veniva misurata quando il valore si stabilizzava, quindi non necessariamente subito dopo il termine del caricamento della pagina. A tal proposito ho notato un comportamento anomalo di Opera sulla pagina di demo di gwt-ext, per cui la memoria occupata è continuata ad aumentare col tempo al ritmo ci 100k al secondo, facendomi pensare in un primo momento ad un potenziale memory leak, salvo poi stabilizzarsi trascorso qualche minuto.

Le estensioni usate nell’ultimo test (Firefox 3.0RC3 + ext) sono: Adblock Plus + Adblock Filterset.G Updater, DownloadHelper, Firebug, Fission, Flagfox, Operator, PicLens e WebDeveloper. Noterete che il maggior consumo di memoria in presenza delle estensioni è anche in funzione della pagina caricata. È per colpa di Firebug? Di WebDeveloper? Dovrei indagare ulteriormente.

I consumi indicati sopra si riferiscono chiaramente alla situazione particolare in cui il browser è stato appena avviato. Già dopo aver lasciato la pagina di test, la memoria occupata si riduce ma non ritorna a quella occupata dal browser appena avviato. Non ho messo del grafico questi valori. Mi sono soffermato però sul valore osservato con Safari dopo aver lasciato il demo di GWT Ext, cioè 44Mb, un valore distante dai 14 iniziali. Disabilitando la cache la memoria non rilasciata si riduce di poco, così che circa 25Mb vengono comunque tenuti occupati. Oltre la cache Safari usa la memoria anche per altro. Cosa?

La risposta a questa domanda l’ho trovata con Instruments. Ho usato il template “Object Allocator” per tracciare l’attività di Safari. La categoria più consistente di oggetti allocati e non rimossi dopo la chiusuda della pagina di test è quella dei “GeneralBlock-1536″. La gran parte delle voci di questa categoria fanno riferimento a sqlite. Immagino quindi che Safari usi sqlite sono quando è necessario, non rilasciando le risorse da esso occupate così da riutilizzarle dopo.

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?