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.

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…

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?

Page Zoom con Firefox 3

Non molti hanno chiara la misura dell’innovatività della prossima release di Firefox. Alcuni dettagli tecnici possono essere d’aiuto. Ad esempio, è noto che Firefox 3 sarà basato su Cairo, libreria grafica vettoriale open source. Non conoscendo così a fondo come è fatto Firefox non posso valutare fino a fondo le conseguenze di questa novità. Però, dovendo affrontare un problema per un lavoro, ho scoperto alcuni dettagli interessanti a proposito del supporto SVG in Firefox 3. Lo standard SVG prevede l’incorporazione di frammenti XHTML nel codice xml del formato grafico. Ho preso in considerazione questa possibilità per realizzare delle pagine contenenti miniature di documenti XHTML. Ovvero, potendo mettere dentro pagine XHTML oggetti SVG, mi è sembrato ovvio che un frame contenente un frammento HTML, presentato con una trasformazione per ridimensionarne il contenuto potesse presentare l’eventuale contenuto HTML ridimensionato graficamente, per esempio del 50% o del 70%. Una cosa diversa dal ridimensionare ogni singolo attributo del frammento HTML, soluzione tradizionalmente adottata in questi casi e che ha diverse controindicazioni (prima: la complessità). Però al momento non è possibile utilizzare questa soluzione perché non c’è un browser, Firefox 2 incluso, in grado di renderizzare HTML dentro SVG. Al contrario, Firefox 3 prevede questa possibilità. Ho provato con l’ultima release alpha di FF3 e sembra che la soluzione funzioni, fatta eccezione per un bug presente sulla versione mac che fa si che sui font non venga applicata correttamente la trasformazione.

Magari prossimamente pubblico un esempio con tanto di codice.