Internet Explorer 9 è vecchio, lo dice Mozilla. Microsoft risponde

Internet Explorer 9 è vecchio, lo dice Mozilla. Microsoft risponde

Nei giorni scorsi Mozilla ha sollevato critiche nei confronti di Internet Explorer 9 accusando Microsoft di aver rilasciato test parziali. Microsoft ha risposto sottolineando quale sia la propria visione di browser moderno

di pubblicata il , alle 11:54 nel canale Web
MicrosoftMozilla
 
I migliori sconti su Amazon oggi

AVM FRITZ!Repeater 1200 AX Edition International, Ripetitore - Wi-Fi 6 extender Dual Band con 2.400 Mbit/s (5 GHz) & 600 Mbit/s (2,4 GHz), Mesh, Access Point, 1x Gigabit LAN, Interfaccia in italiano

Compra ora
85 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
wal7er22 Febbraio 2011, 23:28 #81
Originariamente inviato da: stecciu
ma nessuno di voi a mai sviluppato un sito con IE? Qualsiasi versione essa sia..
Non è vecchio o nuovo.. E' da non usare.


Quoto in pieno!!

E aggiungo:
Qualcuno di voi ha mai fatto un giro nel DOM per modificare qualcosa?

Si deve sempre aggiungere un pezzo di codice che tratta in modo differente il caso "sfigato" di ie.
hexaae22 Febbraio 2011, 23:46 #82
Sì ok, questo era con IE6,7,8.
Avete provato con IE9 o è per principio?
http://www.quirksmode.org/dom/w3c_css.html
http://www.quirksmode.org/dom/w3c_html.html
http://www.quirksmode.org/dom/w3c_core.html
(non aggiornati alla IE9RC)
blackshard23 Febbraio 2011, 00:18 #83
Originariamente inviato da: devil_mcry
figo, siete arrivati a parlare di thread, pthread e fork

a quando la discussione tra control unit microprogrammata e hardwired ?

cmq black, i thread hanno nel loro definitore, l'id del thread, uno stack e la copia dei registri compreso program counter

ogni pcb ha l'elenco dei thread che gli appartengono

a scuola ci hanno fatto un disegnino esplicativo se mi viene lo metto poi ma è abb. ot


Si, i thread di livello kernel (su windoze) hanno tutto quello che serve per essere schedulati indipendentemente. Il processo propriamente detto ormai è un retaggio del passato, più che altro è un "contenitore" di risorse e di thread. Poi ci sono anche i thread di livello utente, che fanno capo ad uno o più kernel thread e vengono schedulati localmente piuttosto che dal SO.
Comunque il PCB "didattico" è un po' semplificato: ricordo che sul libro di SO (Silberschatz) si faceva riferimento al fatto che la struct del PCB nel kernel di linux versione 1 era qualcosa tipo 30 righe di codice, mentre nella versione 2.4 diventava 120 righe di codice o giù di lì...
shodan23 Febbraio 2011, 19:05 #84
Originariamente inviato da: blackshard
Non sono del tutto d'accordo. Sull'overhead di un processo, non ho idea attualmente quante risorse siano destinate da un moderno sistema operativo ad ogni processo. Di sicuro lo stack ce l'hanno anche i thread, che oggigiorno sono le entità schedulabili e quindi hanno il loro bravo stack.


Ciao,
alcuni anni fa analizzai la situazione su un kernel 2.6 e ricordo abbastanza chiaramente che i valori di overhead erano quelli indicati sopra. Non so però se con gli ultimi le cose sono cambiate...
Comunque, alla luce della quantità di memoria odierna e del numero di schede che un utente può realisticamente aprire (100 ?) stiamo parlando di valori risibili.

Per lo scambio di dati, immagina di aprire una, due o più tab che puntano a pagine con le stesse risorse (per esempio il forum). Non so se chrome gestisca la cosa, ma caricare in memoria tante istanze dello stesso elemento non è una bella cosa. Certo, puoi utilizzare la memoria condivisa che è una bella cosa, ma ti serve sempre un processo centralizzato che la gestisce, e quindi altro IPC e se va' in crash lui vanno in crash tutti quanti lo stesso.


Mmm... ovviamente andrebbe testato, ma non credo proprio che Firefox carichi in memoria gli elementi condivisi da più pagine una sola volta. Se riesco a recuperare qualche minuto provo e posto i risultati...

Eh però pthreads è un po' un terreno minato, visto che in base all'implementazione gestisce thread di livello utente e thread di livello kernel.


Vero, ma come libreria è tra le più complete e veloci. Ma siamo tremendamente OT: li ho menzionati solo per fare l'esempio di un caso in cui migliaia di thread sono gestiti in modo molto migliore che un pari numero di processi. Ma qui siamo in ambito browser, decisamente diverso...

Comunque si, il fork è sempre più costoso, anche se apache aveva una gestione un po' diversa: il processo non terminava al termine della connessione, ma veniva mantenuto attivo per un tot di connessioni, poi veniva terminato e rinnovato per evitare leaks e per evitare costosi fork. Questo almeno nelle ultime incarnazioni della versione 1.x prefork.


Vero anche questo: proprio per evitare la (relativa) penalizzazione di creare un nuovo processo, veniva effettuato un "late kill" (e anche un "prefork" sui processi ormai liberi.

Non conosco la definizione di working set privato, però hai ragione riguardo al fatto che come il browser usa la memoria è conosciuto solo agli sviluppatori. Magari uno utilizza una cache per oggetti di un certo tipo che l'altro non usa, e così via...


Per quanto riguarda il working set privato, la definizione è semplice: è quella parte del working set che riguarda aree di memoria con permessi di scrittura e quindi "privata" (temine in parte improprio) dell'applicazione. In pratica, rispetto al working set "e basta" esclude le aree contenenti il codice.

In ordine di grandezza puoi vedere le cose così: VMMSIZE (indirizzi di memoria mappati dalla MMU ma non necessariamente utilizzati), RSS (resident set size, il working set insomma), private RSS (working set privato) e shared RSS (memoria condivisa presente nel working set). Ho usato le terminologie UNIX, non so se Windows ne adotta altre...

Ciao.
shodan24 Febbraio 2011, 11:45 #85
Allora, dato che l'argomento mi interessava, ho fatto qualche test mettendomi nei panni di un utente Windows. Prima di condividere i risultati però premetto che:
a) non ho nessuna pretesa di essere esaustivo e/o nel giusto
b) sono aperto a qualunque critica / osservazione (anzi sono benvenute).

Chrome e Firefox sono stati provati sotto Win 7 x64 installato su un portatile Dell E6410 con i5 540 e 4 GB di RAM. Per effettuare il test, ho aperto dapprima 1 e poi 5 tab puntanti tutti verso www.hwupgrade.it

Di seguito i risultati con 1 tab aperto:
[CODE]
CHROME (n.3 processi)
WS / WP / SH
109352 / 51772 / 27220
Memoria totale utilizzata (WS - SH) = 82132

Firefox (n.1 processo firefox + n.1 processo plugin flash)
WS / WP / SH
83840 / 50604 / 16976
Memoria totale utilizzata (WS - SH) = 66864

Risparmio di memoria totale con firefox: 15268
Risparmio di memoria per tab con firefox: 15268
[/CODE]
Con un solo tab aperto Firefox consente un risparmio di circa 15 MB di RAM in quanto apre un solo processo (+ uno per il flash) contro i 3 processi di Chrome (che tra l'altro lancia il plugin flash una sola volta, probabilmente all'interno del processo master).

Ora i risultati con 5 tab aperti:
[CODE]
CHROME (n.7 processi)
WS / WP / SH
304636 / 180048 / 96024
Memoria totale utilizzata (WS - SH) = 208612

Firefox (n.1 processo firefox + n.1 processo plugin flash)
WS / WP / SH
187652 / 146760 / 22952
Memoria totale utilizzata (WS - SH) = 164700

Risparmio di memoria totale con firefox: 43912
Risparmio di memoria per tab con firefox: 8782
[/CODE]
Con 5 tab aperti Firefox consente un risparmio di memoria di circa 44 MB ma il risparmio per tab è di soli 8 MB.

Per curiosità ho anche provato a monitorare l'uso CPU durante la visione di un semplice filmato a 720p (lo trovate qui: http://www.youtube.com/watch?v=VATNyBTPltI) e ho rilevato un uso del processore molto simile (~7% Firefox, ~8% Chrome).

In sostanza: secondo me la minore occupazione di memoria di Firefox non è un vantaggio reale, in quanto troppo limitata. Ipotizzando che rimanga a 8 MB per tab, infatti, anche aprendo 50 tab (10 volte il numero testato) ci sarebbe un risparmio di circa 80 MB: non male, ma ininfluente sulla dotazione standard di un qualunque PC da 5/6 anni a questa parte. Tra l'altro, ho avuto l'impressione che l'uso di RAM da parte di Firefox crescesse in modo molto lento ma costante anche quando ero in idle e sostanzialmente non facevo nulla.

EDIT: ho realizzato solo ora che ho fatto male la moltiplicazione!
Su 50 tab il vantaggio potrebbe arrivare anche a ~400 MB ma, vedendo come scende il costo per tab con l'aumentare degli stessi, probabilmente siamo più nel range dei ~200 MB. Non penso però che il maggior consumo derivi dall'uso dei processi rispetto ai thread, e comunque 50 tab non sono pochi

Sotto Linux i risultati sarebbero probabilmente comparabili, se non addirittura con margini di vantaggio per Firefox più risicati (da quanto ho visto Linux tende a condividere le porzioni di codice con più aggressività.

Sull'altro lato della bilancia vanno messi i noti problemi di stabilità (un crash di un tab mi chiude tutto il browser) e da questo punto di vista, a mio avviso, Chrome è vincitore.

Poi ovviamente ci sono i problemi di Licenza (con relative clausole) del browser di Google, ma questa è un'altra storia...

Spero sia una comparazione interessante
Ciao.
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^