-
Possiamo fare un piccolo aggiustamento
-
nel nostro codice per evitare
-
un eccessivo tasso di abbandono.
-
Diamo uno sguardo a una vista confronto.
-
Invece di concatenare un valore di cella
-
nel momento di costruire ogni riga,
-
invece lesempio di StringBuilder,
-
e costruiamo ogni riga
-
con una singola stringa.
-
Si noti che lo StringBuilder
-
si trova al di fuori del ciclo, e
-
così la sua memoria è assegnata una volta.
-
E poi lo usiamo semplicemente
come un buffer per
-
ogni iterazione del ciclo dove
prima lo ripuliamo, e poi aggiungiamo
-
una singola stringa di ints
-
per rappresentare
la riga per quella iterazione del ciclo.
-
Ora, guarda le note dellinsegnate per
-
maggiori dettagli su questo segmento di
-
codice.
-
Bene, ora è il momento di verificare.
-
è il arrivato il momento di continuare e
caricare il ramo di codice migliorato,
-
che si chiama memory_churn_optimized,
-
sia in modalitŕ di tracciamento
-
che di monitoraggio della memoria
-
Per confermare di aver ridotto la quantità
-
di GC della finestra a breve termine.
-
Si puň anche utilizzare l indicatore
-
di assegnazione per verificare.
-
Se si utilizza l indicatore di assegnazione, o
-
se si ha qualcosa di
-
inaspettato in modalità traccia
-
o monitoraggio di memoria.
-
Condividi uno screenshot del tuo
risultato nei forum di discussione.
-
Siamo interessati a
vedere quello che hai ottenuto.
-
Ora per noi, anche con questi cambiamenti,
il Perf Pirate si blocca ancora.
-
Ma questa volta per meno tempo.
-
Ora questo punto,
-
questo potrebbe anche significare
-
che questa funzione probabilmente sia una
-
buona opzione da essere messa
-
in background.
Udacity