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

Question

C'è molto capitale C, informatica di capitale S che va in Javascript tramite i progetti Tracemonkey, Squirrelfish e V8. Qualcuno di questi progetti (o altri) affronta le prestazioni delle operazioni DOM, o si tratta di calcoli puramente Javascript correlati?

Answer 1

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

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

Un esempio del primo è la dipendenza di TraceMonkey da tutte le chiamate alle funzioni JS. Poiché una traccia allinea efficacemente il percorso di esecuzione in qualsiasi punto in cui il JS colpisce il codice che non può essere inline (codice nativo, ricorsione polimorfica vera, gestori di eccezioni) la traccia viene interrotta e l'esecuzione ricade all'interprete. Gli sviluppatori di TM stanno facendo parecchio lavoro per migliorare la quantità di codice che può essere rintracciata (inclusa la gestione della ricorsione polimorfica), ma la tracciabilità realistica attraverso chiamate a funzioni native arbitrarie (ad esempio il DOM) non è fattibile. Per questo motivo ritengo che stiano cercando di implementare più DOM in JS (o almeno in modo amichevole con JS). Detto questo, quando il codice è rintracciabile, TM può fare un lavoro eccezionalmente buono in quanto può ridurre la maggior parte degli "oggetti" a equivalenti più efficienti e/o nativi (ad esempio, utilizzare gli input macchina invece dell'implementazione del numero JS).

JavaScriptCore (che è dove SquirrelFish Estrema vive) e V8 hanno un approccio più simili in quanto entrambi JIT immediatamente tutto il codice JS e produrre codice che è più speculativa (ad es. Se si stanno facendo a*b generano codice che assume a e b sono numeri e ricade su codice eccezionalmente lento se non lo sono). Questo ha un certo numero di vantaggi rispetto alla traccia, vale a dire che è possibile generare tutto il codice, indipendentemente dal fatto che chiami o meno codice nativo/eccezioni, ecc, il che significa che una singola chiamata DOM non distruggerà le prestazioni. Lo svantaggio è che tutto il codice è speculativo - TM sarà chiamate in linea a Math.floor, ecc., Ma il migliore JSC/V8 può essere 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. La ragione di ciò è la compilazione iniziale, mentre il codice TM solo JIT dopo la sua esecuzione (e quindi sa esattamente quale funzione è stata chiamata) JSC e V8 non hanno una base reale per fare una tale assunzione e fondamentalmente devono indovinare (e al momento nessuno dei due tentativi Questo). L'unica cosa che V8 e JSC fanno per cercare di compensare questo problema è di tenere traccia di ciò che hanno visto in passato e incorporarlo nel percorso di esecuzione, entrambi usano una combinazione di tecniche per fare questo caching, in casi particolarmente caldi riscrivono piccole porzioni del flusso di istruzioni e in altri casi tengono fuori dalla cache le cache.In linea di massima, se si dispone di codice che va

a.x * a.y 

V8 e JSC controllerà il 'tipo implicita'/'Struttura' due volte - una volta per ogni accesso, e quindi verificare che a.x e a.y sono entrambi i numeri, mentre TM genererà il codice che controlla il tipo di a solo una volta e può (a parità di condizioni) solo moltiplicare a.x e a.y senza verificare che siano numeri.

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

L'altro problema che ho citato è stato il costo di associazione del DOM < -> JS - questo può effettivamente giocare un ruolo molto significativo nelle prestazioni web, il migliore esempio di Safari 3.1/2 vs Chrome nel benchmark Dromaeo. Chrome si basa sul ramo di 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, questo è fondamentalmente dovuto a legature più efficienti tra JSC/WebCore (dom/rendering/etc di WebKit) e V8/WebCore

Attualmente guardando le associazioni DOM di TM sembra ingiusto in quanto non hanno completato tutto il lavoro che vogliono fare (ahimè) in modo che solo ripiegare sulla 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 non venga implementata una particolare chiamata del metodo DOM in JS, avranno scarso effetto (per non dire che non è stato fatto alcun lavoro per ridurre l'overhead di tali chiamate).

ottimizzazione DOM è un intero 'nother caldaia di scoiattoli scimmie ragni di pesce ... il layout e persino motori di rendering entrare in gioco, e ogni browser ha la propria strategia di implementazione e ottimizzazione.