24

Sto analizzando il seguente utilizzo di memoria del codice utilizzando la linea temporale in Chrome Dev Tools v27.requestAnimationFrame garbage collection

<!DOCTYPE html> 
<html> 
<head> 
    <meta http-equiv='content-type' content='text/html; charset=UTF-8' /> 
    <title>RAF</title> 
</head> 
    <body> 
    <script type='text/javascript' charset='utf-8'> 
     var frame = function() { 
     window.webkitRequestAnimationFrame(frame); 
     }; 
     window.webkitRequestAnimationFrame(frame); 
    </script> 
    </body> 
</html> 

Avviso è semplice. Ma alla fine vedo apparire il modello di un dente che indica che il garbage collector sta recuperando memoria.

Chrome Dev Tools Timeline

Vuol raf creare oggetti spazzatura di default? C'è un modo per evitarlo? Grazie.

+0

Correlato. Sembra che ci siano più potenziali problemi in questo settore. Vorrei consigliare di prendere l'output dell'intero strumento di monitoraggio della memoria con un pizzico di sale? Onestamente, non sono sicuro di cosa concludere da tutto ciò. http://stackoverflow.com/questions/19395565/chrome-requestanimationframe-issues –

+0

Im mettere una taglia su questo se qualcun altro è disposto a fare lo stesso:> Stava già pensando se potrebbe aiutare ad avere due funzioni capovolgere flop si registrano a vicenda. –

risposta

2

Sembra un ciclo di trattenere. Frame si sta chiamando così mantiene un conteggio dei ritardi e non viene rilasciato. Inoltre, ogni volta che si monitora il codice in esecuzione con profilo, timeline o stack di heap, ci saranno alcuni effetti collaterali.

In entrambi i casi non me ne preoccuperei. Ci sono problemi molto più grandi da affrontare se stai cercando di ottenere la tua app o il tuo rendimento. Finché JS termina in under 16ms, nessuno noterà mai nulla.

I maggiori problemi di memoria/CPU sono: le chiamate di rete, decomprimere PNG/JPG, creando e distruggendo elementi DOM, l'elaborazione dei dati/di analisi su un thread non-lavoratore, cattivo uso di texture GPU e l'assegnazione molti dati a causare la GC impiegherà molto tempo per raccogliere dati.

Sono stato in grado di ottimizzare una lista di scorrimento con 1.000.000 di elementi da eseguire a 120 FPS su cromo (https://github.com/puppybits/BackboneJS-PerfView). Gli strumenti per le prestazioni dovrebbero aiutarti a trovare i maggiori problemi che l'utente può vedere e non devi preoccuparti delle cose minori.

+0

Ehi lì! Hai qualche idea di come usare questa idea per le animazioni rAF forse? – thednp

4

enter image description here

ho scoperto quanto segue: Se si modifica la funzione di RAF in due "ping-pong", come funzioni, si ottiene molto meno spazzatura. Non è possibile evitare il primo "grosso GC" iniziale, ma dopo di ciò si vedono solo GC secondari di circa 50kb invece di GC 700kb-1mb. Il codice sarà simile a questa:

<script type='text/javascript' charset='utf-8'> 
    window.frameA = function() { 
    window.webkitRequestAnimationFrame(window.frameB); 
    }; 
    window.frameB = function() { 
    window.webkitRequestAnimationFrame(window.frameA); 
    }; 
    window.webkitRequestAnimationFrame(window.frameA); 
</script> 

Credo che questo è il meglio che si può fare in Chrome. Ho notato che in FF gli intervalli gc o la memoria cambiano difficilmente, quindi è probabilmente correlata al roug di debugging (vedere il rapporto bug relativo al bug di cui sopra per maggiori dettagli). Tuttavia, ho notato un miglioramento nel mio stesso gioco durante la distribuzione di RAF in questo modo - e diamine ho bisogno di essere in grado di eseguire il debug senza GC artificiali che non si verifichino su macchine normali degli utenti.

+1

Sono scioccato nel dire che questo funziona. Incredibile scoperta, non riesco nemmeno a immaginare cosa ti abbia fatto provare questo.:) – Jaruba

+0

Non vedo questo lavoro – kevzettler

+0

Kevzettler: È stato sempre un hack che (si spera) sarebbe diventato obsoleto un giorno. Puoi dirci quale Browserversion hai provato? Osservi ancora il problema gc in generale? Modificheremo la risposta di conseguenza. –