Per memorizzare o non memorizzare nella cache un oggetto ReadOnlyWrapper?

Question

Per memorizzare o non memorizzare nella cache un oggetto ReadOnlyWrapper?

#1 da (1 voti)
#2 da (0 voti)

0

Ho un sistema con una struttura come questa:

Il ConcreteWriteable memorizza nella cache ReadOnlyWrapper .

Questo è un sistema simile a quello che%'sSystem.Array utilizza per il suo metodo Array.AsReadOnly<T>(T[] array) (ignorando per il momento che System.Array 's AsReadOnly è statico). Tuttavia, guardando il codice per System.Array all'origine di riferimento, System.Array.AsReadOnly restituisce ogni volta un nuovo wrapper, mentre sto creando il wrapper allo stesso tempo di ConcreteWriteable e lo sto memorizzando nella cache, quindi restituisco lo stesso ogni tempo.

Questo mi ha fatto pensare, c'è qualche ragione per cui non dovrei farlo? C'è qualche ragione per cui la creazione di un nuovo wrapper ogni volta è più desiderabile che restituire lo stesso wrapper (tenendo presente che il wrapper non può modificare il ConcreteWriteable ed è effettivamente un wrapper, non una copia)?

design

posta Pharap 24.12.2014 - 20:19

fonte

2 risposte

Leggi altre domande sui tag design

Affrontando MemoryError in Python Quale design è migliore? [MainClass] - [Class] OR [Main Class] - [Middle Class] - [Class]

score 1 · Answer 1

Se il wrapper è veramente immutabile, il comportamento del programma è identico se si crea un nuovo wrapper ogni volta o se ne riutilizza uno. L'unica differenza è il thrashing del garbage collector.

Ho pensato di usare le struct come wrapper di raccolta di sola lettura, invece di istanze di classe, ma ho capito che ci sarebbe stato poco guadagno, dal momento che spesso una collezione è lanciata come un'interfaccia di raccolta, che avrebbe riquadrato la struttura.

score 0 · Answer 2

Non memorizzare nella cache.

Tecnicamente: come già detto Frank, la differenza è il garbage collector. Se lo metti in cache, i tuoi oggetti verranno spostati nel vecchio spazio java, dove gli oggetti di cimatura sono lenti e dolorosi. Mentre cestinare oggetti nel nuovo spazio oggetti, viene a costo zero, perché questo elemento non viene semplicemente più toccato. Ma se si mantengono gli oggetti senza motivo, questo oggetto viene copiato da una metà del nuovo spazio oggetti all'altro, poiché esiste un percorso per questo oggetto - La VM presuppone: Deve essere abbastanza importante da conservare. L'oggetto sta invecchiando nel nuovo spazio e copiato ogni volta, dove produce (copia) i costi. In questo modo, gli oggetti di memorizzazione nella cache producono dei costi vivendo e sono molto più costosi da pulire, una volta raggiunti i vecchi spazi.

Design: lascia sempre decidere al consumatore della tua API, per quanto tempo deve vivere un oggetto. Come designer, non disponi di queste informazioni durante la progettazione dell'API / della classe.

Ottimizzazione prematura: dovresti anche evitare l'ottimizzazione prematura. Non tutti i caching sono un grande guadagno. Ottimizza, quando c'è una buona ragione, ma evitalo se rende il codice meno leggibile senza troppi guadagni - evita microottimizzazioni. Se è necessaria un'istanza di memorizzazione nella cache, non eseguirla per impostazione predefinita, ma fornire una "fabbrica" che fornisca gli oggetti di memorizzazione nella cache, che contiene il codice di memorizzazione nella cache. La tua VM arriverà con nuove strategie di ottimizzazione ogni volta che ne avrai una più nuova. Se hai bisogno di velocità, è preferibile scegliere algoritmi migliori invece di utilizzare microottimizzazioni.

Creazione di oggetti: ultimo ma non meno importante, la "nuova" operazione non è molto costosa. Non c'è bisogno di evitarlo.