Oggetti immutabili che cambiano costantemente memoria / prestazioni?

5

Sto scrivendo un programma che va in loop e continua a cambiare lo stato di alcuni modelli (simile a un gioco). Naturalmente, molte cose sono mutabili. Tuttavia, sto anche scrivendo alcune classi che sono immutabili perché sono trattate intrinsecamente come valori (ad esempio: vettori, matrici, ecc.)

Tuttavia, questi valori cambiano su ogni ciclo (forse 50-100 volte al secondo). Questo significa che ad ogni cambiamento, il programma dovrebbe allocare un nuovo blocco di memoria? Se sto usando il codice gestito, significa che l'utilizzo della memoria si accumulerà molto rapidamente? In che modo ciò influisce sul determinismo, sulle prestazioni e sulla garbage collection in linguaggi come C # e Java, specialmente quando molti garbage collector devono mettere in pausa l'intero programma per cancellare la memoria?

    
posta 9a3eedi 17.07.2014 - 12:02
fonte

2 risposte

2

Tutti structs sono allocati sullo stack o fanno parte della memoria contenente class . Anche se si allocano milioni di strutture, non avrà alcun impatto sulla memoria. D'altro canto, il passaggio di una grande struttura attorno al valore (non per riferimento) potrebbe influire sulle prestazioni, poiché viene copiato ogni volta.

D'altra parte, l'allocazione di nuovo class potrebbe influire sul consumo di memoria, perché nuova istanza di classe = nuova memoria allocata. Inoltre, potrebbe avere un impatto sulle prestazioni, perché GC deve tenerne traccia e disporne. Ci sono alcune ottimizzazioni come GC generazionale, ma se hai davvero bisogno di prestazioni, è meglio gestire la memoria da solo.

    
risposta data 17.07.2014 - 15:29
fonte
2

Se hai bisogno di qualcosa che si comporta come un gruppo di variabili indipendenti ma legate insieme con del nastro adesivo (ad esempio le coordinate di un vettore), usa una struttura campo esposto . I campi di una struttura di campo esposto sono mutabili quando la struttura è memorizzata in una posizione mutabile e immutabili quando la posizione di archiviazione è memorizzata in una posizione immutabile.

Poiché una struttura a campo aperto si comporta come un mucchio di variabili indipendenti ma correlate, alcune persone che pensano che tutto dovrebbe comportarsi come un oggetto le deride come "malvagie". Direi che, sebbene le strutture a campo aperto o altrimenti mutevoli non siano generalmente adatte in luoghi che richiedono qualcosa che si comporta come un oggetto, sono perfette in posti dove si avranno bisogno di un mucchio di variabili incollate insieme con del nastro adesivo.

È possibile utilizzare oggetti di classe immutabili per contenere mazzi di valori indipendenti ma correlati. Può anche essere vantaggioso nei casi in cui i valori compositi (cioè una particolare combinazione di valori) saranno trasmessi molto più frequentemente di quanto non siano stati creati. D'altra parte, se il codice che contiene un riferimento a un vettore (34,39) vuole contenere un riferimento a un vettore il cui componente x è uno più grande, non sarà in grado di incrementare semplicemente un campo (come potrebbe una struttura) ma deve invece creare un oggetto vettoriale completamente nuovo (35,39). Il costo delle prestazioni di fare questo non sarà un problema se non si debbano mai eseguire tali operazioni ripetutamente all'interno di un loop interno. D'altro canto, se un programma eseguisse frequentemente loop significativi il cui scopo principale fosse la costruzione di versioni leggermente modificate di oggetti, il tempo necessario per costruire tali oggetti potrebbe diventare una frazione sostanziale del tempo di esecuzione complessivo.

    
risposta data 21.07.2014 - 23:30
fonte

Leggi altre domande sui tag