In che modo i vari progetti di ottimizzazione Javascript influiscono sulle prestazioni del DOM?

Question

C'è un sacco di maiuscola C, maiuscola S che va in Javascript tramite i progetti Tracemonkey, Squirrelfish e V8. Qualcuno di questi progetti (o altri) riguarda l'esecuzione di operazioni DOM o sono puramente correlati al calcolo Javascript?

Answer 1

Le prestazioni di operazioni DOM pure (getElementById / Tagname / Selector, nextChild, ecc.) non sono influenzate poiché sono già in C ++ puro.

Il modo in cui i miglioramenti del motore JS influiranno sulle prestazioni dipende in parte dalle particolari tecniche utilizzate per i miglioramenti delle prestazioni, nonché dalle prestazioni del ponte DOM- > JS.

Un esempio del primo è la dipendenza di TraceMonkey da tutte le chiamate verso le funzioni JS. Poiché una traccia integra efficacemente il percorso di esecuzione in qualsiasi punto in cui JS rileva il codice che non può essere incorporato (codice nativo, ricorsione polimorfica vera, gestori di eccezioni) la traccia viene interrotta e l'esecuzione ricade sull'interprete. Gli sviluppatori di TM stanno facendo un sacco di lavoro per migliorare la quantità di codice che può essere rintracciato (inclusa la gestione della ricorsione polimorfica), tuttavia non è possibile rintracciare realisticamente attraverso chiamate a funzioni native arbitrarie (ad esempio il DOM). Per questo motivo credo che stiano cercando di implementare più DOM in JS (o almeno in modo amichevole JS). Detto questo, quando il codice è rintracciabile TM può fare un lavoro eccezionalmente buono in quanto può abbassare la maggior parte degli "oggetti". a equivalenti più efficienti e / o nativi (ad es. utilizzare gli input macchina anziché l'implementazione del numero JS).

JavaScriptCore (che è dove vive SquirrelFish Extreme) e V8 hanno un approccio più simile in quanto entrambi JIT tutto il codice JS immediatamente e producono un codice che è più speculativo (ad es. se stai facendo a * b generano codice che presuppone che a e b siano numeri e, se non lo sono, ricadono in un codice eccezionalmente lento. Ciò ha una serie di vantaggi rispetto alla traccia, vale a dire che è possibile eseguire il jit di tutto il codice, indipendentemente dal fatto che chiami codice nativo / genera eccezioni, ecc. Ciò significa che una singola chiamata DOM non distruggerà le prestazioni. Il rovescio della medaglia è che tutto il codice è speculativo - TM farà le chiamate in linea a Math.floor, ecc., Ma il miglior JSC / V8 può fare sarebbe equivalente a a = Math.floor (0,5 ) - > a = (Math.floor == realFloor)? inline: Math.floor (0.5) questo ha costi sia in termini di prestazioni che di utilizzo della memoria, inoltre non è particolarmente fattibile. Il motivo di ciò è la compilazione anticipata, mentre TM solo il codice JIT dopo l'esecuzione (e quindi sa esattamente quale funzione è stata chiamata) JSC e V8 non hanno basi reali per fare un tale presupposto e sostanzialmente devono indovinare (e attualmente nessuno dei due tentativi Questo). L'unica cosa che V8 e JSC fanno per cercare di compensare questo problema è tenere traccia di ciò che hanno visto in passato e incorporarlo nel percorso di esecuzione, entrambi utilizzano una combinazione di tecniche per eseguire questa memorizzazione nella cache, in casi particolarmente caldi riscrivono piccole porzioni del flusso di istruzioni e in altri casi mantengono la cache fuori banda. In generale, se si dispone di codice che va

a.x * a.y

V8 e JSC controlleranno il 'tipo implicito' / 'Struttura' due volte - una volta per ogni accesso, quindi controlleranno che ax e ay siano entrambi numeri, mentre TM genererà il codice che controlla il tipo di a una sola volta e può (a parità di condizioni) moltiplicare ax e ay senza controllare che sono numeri.

Se stai osservando la pura velocità di esecuzione attualmente c'è qualcosa di misto, dato che ogni motore sembra fare meglio in alcuni compiti rispetto ad altri - TraceMonkey vince in molti test di matematica pura, V8 vince in casi fortemente dinamici, JSC vince se c'è un mix. Ovviamente, mentre è vero oggi, potrebbe non essere domani, poiché stiamo tutti lavorando sodo per migliorare le prestazioni.

L'altro problema che ho citato era il costo di associazione DOM < - > JS - questo può effettivamente svolgere un ruolo molto significativo nelle prestazioni web, il miglior esempio di questo è Safari 3.1 / 2 vs Chrome nel benchmark Dromaeo. Chrome si basa sul ramo Safari 3.1 / 2 di WebKit, quindi è ragionevolmente sicuro assumere prestazioni DOM simili (la differenza del compilatore potrebbe causare un certo grado di varianza). In questo benchmark Safari 3.1 / 2 batte effettivamente Chrome nonostante abbia un motore JS che è chiaramente molto più lento, ciò è sostanzialmente dovuto a legami più efficienti tra JSC / WebCore (la dom / rendering / etc di WebKit) e V8 / WebCore

Attualmente guardare i binding DOM di TM sembra ingiusto in quanto non hanno completato tutto il lavoro che vogliono fare (ahimè) quindi ricadono sull'interprete :-(

..

Errmmm, che è andato avanti un po 'più a lungo del previsto, quindi la risposta breve alla domanda originale è "dipende" : D

Answer 2

Sono puro JavaScript. A meno che un particolare metodo DOM non sia implementato in JS, avranno scarso effetto (per non dire che non è stato fatto alcun lavoro per ridurre il overhead di tali chiamate ).

L'ottimizzazione del DOM è un intero 'altro bollitore di scoiattoli scimmie spiders pesci ... Il layout e persino i motori di rendering entrano in gioco, e ogni browser ha la propria strategia di implementazione e ottimizzazione.