Strutture contro classi

Sto per creare 100.000 oggetti nel codice. Sono piccoli, solo con 2 o 3 proprietà. Li inserirò in un elenco generico e quando lo saranno, li collegherò in loop e controllerò il valore ae forse aggiornerò il valore b.

È più veloce / migliore creare questi oggetti come classe o come struttura?

MODIFICARE

un. Le proprietà sono tipi di valore (eccetto la stringa che penso?)

b. Potrebbero (non siamo ancora sicuri) avere un metodo di convalida

MODIFICA 2

Mi chiedevo: gli oggetti nell'heap e nello stack vengono elaborati allo stesso modo dal Garbage Collector o funziona in modo diverso?

È più veloce creare questi oggetti come classe o come struttura?

Sei l'unica persona che può determinare la risposta a questa domanda. Provalo in entrambi i modi, misura una metrica delle prestazioni significativa, incentrata sull'utente e pertinente, quindi saprai se il cambiamento ha un effetto significativo sugli utenti reali in scenari pertinenti.

Le strutture consumano meno memoria heap (perché sono più piccole e più facilmente compattate, non perché sono "nello stack"). Ma la copia richiede più tempo rispetto a una copia di riferimento. Non so quali siano le tue metriche sulle prestazioni per l'utilizzo della memoria o la velocità; c'è un compromesso qui e tu sei la persona che sa cos'è.

È meglio creare questi oggetti come classe o come struttura?

Forse classe, forse struttura. Come regola generale: se l'oggetto è:
1. Piccolo
2. Logicamente un valore immutabile
3. Ce ne sono molti
Quindi prenderei in considerazione di renderlo uno struct. Altrimenti mi atterrei a un tipo di riferimento.

Se hai bisogno di mutare qualche campo di una struttura, di solito è meglio costruire un costruttore che restituisca un'intera nuova struttura con il campo impostato correttamente. Forse è leggermente più lento (misuralo!) Ma logicamente molto più facile da ragionare.

Gli oggetti nell'heap e nello stack vengono elaborati allo stesso modo dal Garbage Collector?

No , non sono la stessa cosa perché gli oggetti in pila sono le radici della collezione . Il garbage collector non ha bisogno di chiedere "questa cosa nello stack è viva?" perché la risposta a questa domanda è sempre "Sì, è in pila". (Ora, non puoi fare affidamento su questo per mantenere in vita un oggetto perché lo stack è un dettaglio di implementazione. Il jitter può introdurre ottimizzazioni che, ad esempio, registrano quello che normalmente sarebbe un valore dello stack, e quindi non è mai sullo stack quindi il GC non sa che è ancora vivo. Un oggetto registrato può avere i suoi discendenti raccolti in modo aggressivo, non appena il registro che lo tiene non verrà letto di nuovo.)

Ma il garbage collector non deve trattare oggetti in pila come vivo, allo stesso modo in cui gestisce qualsiasi oggetto noto per essere vivo come vivo. L'oggetto nello stack può fare riferimento a oggetti allocati nell'heap che devono essere mantenuti in vita, quindi il GC deve trattare gli oggetti dello stack come oggetti allocati nell'heap vivente allo scopo di determinare il set live. Ma, ovviamente, essi sono non trattati come "oggetti dal vivo" ai fini della compattazione del mucchio, perché non sono sul mucchio, in primo luogo.

È chiaro?

A volte structnon è necessario chiamare il costruttore new () e assegnare direttamente i campi rendendolo molto più veloce del solito.

Esempio:

Value[] list = new Value[N];
for (int i = 0; i < N; i++)
{
    list[i].id = i;
    list[i].isValid = true;
}

è circa 2 o 3 volte più veloce di

Value[] list = new Value[N];
for (int i = 0; i < N; i++)
{
    list[i] = new Value(i, true);
}

dove Valueè a structcon due campi ( ide isValid).

struct Value
{
    int id;
    bool isValid;

    public Value(int i, bool isValid)
    {
        this.i = i;
        this.isValid = isValid;
    }
}

D'altra parte, è che gli elementi devono essere spostati o i tipi di valore selezionati, tutto ciò che la copia ti rallenterà. Per ottenere la risposta esatta sospetto che tu debba profilare il tuo codice e testarlo.

Le strutture possono sembrare simili alle classi, ma ci sono differenze importanti di cui dovresti essere a conoscenza. Prima di tutto, le classi sono tipi di riferimento e le strutture sono tipi di valore. Usando gli struct, puoi creare oggetti che si comportano come i tipi incorporati e goderti anche i loro vantaggi.

Quando chiami l'operatore New su una classe, verrà allocato nell'heap. Tuttavia, quando si crea un'istanza di una struttura, viene creata nello stack. Ciò produrrà miglioramenti delle prestazioni. Inoltre, non avrai a che fare con i riferimenti a un'istanza di una struttura come faresti con le classi. Lavorerai direttamente con l'istanza della struttura. Per questo motivo, quando si passa una struttura a un metodo, viene passata per valore anziché come riferimento.

Di più qui:

http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx

Gli array di strutture sono rappresentati sull'heap in un blocco di memoria contiguo, mentre un array di oggetti è rappresentato come un blocco contiguo di riferimenti con gli oggetti effettivi stessi altrove sull'heap, richiedendo così memoria sia per gli oggetti che per i loro riferimenti all'array .

In questo caso, poiché li stai inserendo in a List<>(e a List<>è appoggiato su un array) sarebbe più efficiente, dal punto di vista della memoria, usare gli struct.

(Attenzione però, gli array di grandi dimensioni troveranno la loro strada nel Large Object Heap dove, se la loro durata è lunga, potrebbe avere un effetto negativo sulla gestione della memoria del processo. Ricorda, inoltre, che la memoria non è l'unica considerazione.)

Se hanno una semantica dei valori, probabilmente dovresti usare una struttura. Se hanno una semantica di riferimento, probabilmente dovresti usare una classe. Ci sono eccezioni, che per lo più tendono a creare una classe anche quando ci sono semantiche di valore, ma inizia da lì.

Per quanto riguarda la seconda modifica, il GC si occupa solo dell'heap, ma c'è molto più spazio sull'heap rispetto allo spazio sullo stack, quindi mettere le cose sullo stack non è sempre una vittoria. Oltre a ciò, un elenco di tipi di struttura e un elenco di tipi di classe saranno nell'heap in entrambi i casi, quindi questo è irrilevante in questo caso.

Modificare:

Comincio a considerare dannoso il termine male . Dopo tutto, rendere mutabile una classe è una cattiva idea se non è attivamente necessario, e non escluderei mai di usare una struttura mutabile. È una cattiva idea così spesso da essere quasi sempre una cattiva idea, ma per lo più semplicemente non coincide con la semantica del valore, quindi non ha senso usare una struttura nel caso specifico.

Ci possono essere ragionevoli eccezioni con gli struct annidati privati, dove tutti gli usi di quello struct sono quindi limitati a un ambito molto limitato. Questo però non si applica qui.

In realtà, penso che "muta quindi è un cattivo stuct" non sia molto meglio che andare avanti con l'heap e lo stack (che almeno ha un certo impatto sulle prestazioni, anche se spesso travisato). "Muta, quindi è molto probabile che non abbia senso considerarlo come semantica del valore, quindi è una struttura sbagliata" è solo leggermente diverso, ma è importante che lo ritenga.

La soluzione migliore è misurare, misurare di nuovo, quindi misurare ancora un po '. Potrebbero esserci dettagli di ciò che stai facendo che potrebbero rendere difficile una risposta semplice e semplificata come "usa strutture" o "usa classi".

Una struttura è, in fondo, niente di più né di meno che un'aggregazione di campi. In .NET è possibile che una struttura "finga" di essere un oggetto, e per ogni tipo di struttura .NET definisce implicitamente un tipo di oggetto heap con gli stessi campi e metodi che, essendo un oggetto heap, si comporteranno come un oggetto . Una variabile che contiene un riferimento a tale oggetto heap (struttura "boxed") mostrerà la semantica di riferimento, ma quella che contiene direttamente una struttura è semplicemente un'aggregazione di variabili.

Penso che gran parte della confusione tra struttura e classe derivi dal fatto che le strutture hanno due casi di utilizzo molto diversi, che dovrebbero avere linee guida di progettazione molto diverse, ma le linee guida MS non fanno distinzione tra di loro. A volte c'è bisogno di qualcosa che si comporti come un oggetto; in tal caso, le linee guida MS sono abbastanza ragionevoli, sebbene il "limite di 16 byte" dovrebbe probabilmente essere più simile a 24-32. A volte, tuttavia, ciò che serve è un'aggregazione di variabili. Una struttura usata a tale scopo dovrebbe semplicemente consistere in un gruppo di campi pubblici e possibilmente un Equalsoverride, ToStringoverride eIEquatable(itsType).Equalsimplementazione. Le strutture usate come aggregazioni di campi non sono oggetti e non dovrebbero fingere di esserlo. Dal punto di vista della struttura, il significato di campo non dovrebbe essere né più né meno che "l'ultima cosa scritta in questo campo". Qualsiasi significato aggiuntivo dovrebbe essere determinato dal codice client.

Ad esempio, se una struttura di aggregazione di variabili ha membri Minimume Maximum, la struttura stessa non dovrebbe prometterlo Minimum <= Maximum. Il codice che riceve una tale struttura come parametro dovrebbe comportarsi come se fosse passato separatamente Minimume Maximumvalori. Un requisito che Minimumnon sia maggiore di Maximumdovrebbe essere considerato come un requisito che un Minimumparametro non sia maggiore di uno passato separatamente Maximum.

Un modello utile da considerare a volte è avere una ExposedHolder<T>classe definita qualcosa come:

class ExposedHolder<T>
{
  public T Value;
  ExposedHolder() { }
  ExposedHolder(T val) { Value = T; }
}

Se uno ha una List<ExposedHolder<someStruct>>, in cui someStructè una struttura variabile aggregazione, uno può fare le cose come myList[3].Value.someField += 7;, ma dando myList[3].Valuead altro codice darà il contenuto di Valuepiuttosto che dare è un mezzo di alterarlo. Al contrario, se si usasse a List<someStruct>, sarebbe necessario usare var temp=myList[3]; temp.someField += 7; myList[3] = temp;. Se si utilizza un tipo di classe mutabile, l'esposizione del contenuto di myList[3]al codice esterno richiederebbe la copia di tutti i campi su qualche altro oggetto. Se si usasse un tipo di classe immutabile, o una struttura "in stile oggetto", sarebbe necessario costruire una nuova istanza che fosse simile, myList[3]tranne quella someFielddiversa, e quindi memorizzare quella nuova istanza nell'elenco.

Una nota aggiuntiva: se si memorizza un gran numero di cose simili, potrebbe essere utile memorizzarle in matrici di strutture possibilmente annidate, preferibilmente cercando di mantenere la dimensione di ogni matrice tra 1K e 64K circa. Le matrici di strutture sono speciali, in quanto l'indicizzazione produrrà un riferimento diretto a una struttura all'interno, quindi si può dire "a [12] .x = 5;". Sebbene sia possibile definire oggetti simili ad array, C # non consente loro di condividere tale sintassi con gli array.

Usa le lezioni.

In una nota generale. Perché non aggiornare il valore b mentre li crei?

Da una prospettiva c ++ sono d'accordo che sarà più lento modificare le proprietà di una struttura rispetto a una classe. Ma penso che saranno più veloci da leggere a causa della struttura allocata sullo stack invece che sull'heap. La lettura dei dati dall'heap richiede più controlli che dallo stack.

Bene, se vai con la struttura dopotutto, elimina la stringa e usa il carattere di dimensione fissa o il buffer di byte.

Questo è re: prestazioni.