C # domanda prestazioni

Question

quandry è - quale dei due seguente metodo funziona in modo ottimale
Goal - ottenere un oggetto di tipo Wrapper (definito di seguito)
Criteri - velocità di memorizzazione
no. di record - circa 1000- 2000 circa, max circa 6K
Scelte - Crea oggetto al volo o fare una ricerca da un
dizionario velocità di esecuzione - chiamato x volte al secondo

NB - ho bisogno di fornire il codice di lavoro prima e poi andare per l'ottimizzazione, quindi, se qualsiasi teorici in grado di fornire scorci dietro le informazioni scena, che ti aiuto prima di arrivare al test vero e prestazioni eventualmente EOD Gio

Definizioni -

class Wrapper  
{  
   public readonly DataRow Row;  
   public Wrapper(DataRow dr)  
   {  
      Row = dr;  
   }  
   public string ID { get { return Row["id"].ToString(); } }  
   public string ID2 { get { return Row["id2"].ToString(); } }  
   public string ID3 { get { return Row["id3"].ToString(); } }  
   public double Dbl1 { get { return (double)Row["dbl1"]; } }  
   // ... total about 12 such fields !  
}  
Dictionary<string,Wrapper> dictWrappers;  

Metodo 1

Wrapper o = new Wrapper(dr);  
/// some action with o
myMethod( o );

Metodo 2

Wrapper o;    
if ( ! dictWrappers.TryGetValue( dr["id"].ToString(), out o ) )    
{    
    o = new Wrapper(dr);    
    dictWrapper.Add(o.ID, o);    
}    

/// some action with o    
myMethod( o );    

Answer 1

Il primo sarebbe più veloce, dal momento che non è in realtà facendo una ricerca, si è solo facendo una semplice allocazione e un compito.

I due segmenti di codice non sono quasi equivalenti. In funzione però, perché il metodo 1 potrebbe creare molti duplicati.

Answer 2

1. Mai ottimizzare senza profilatura prima.
2. Mai profilo a meno che il codice non soddisfa le specifiche / aspettative.
3. Se è necessario al profilo di questo codice, scriverlo in entrambe le direzioni e punto di riferimento con i tuoi carico previsto.

EDIT: Io cerco di favorire il seguente corso di ottimizzazione meno che le prestazioni è inaccettabile:

• Semplicità
• La leggibilità
• manutenibilità
• Testabilità

ho (di recente) visto il codice altamente ottimizzato che è stato molto difficile da eseguire il debug. Ho refactoring per semplificare esso, poi corse test di performance. Lo spettacolo era inaccettabile, così ho profilato che, trovato i colli di bottiglia, e solo quelli ottimizzato. I re-ha eseguito il test di performance, e il nuovo codice era paragonabile alla versione altamente ottimizzata. Ed è ora molto più facile da mantenere.

Answer 3

Ecco un strumento di profiling .

Answer 4

Senza in realtà il test mi aspetterei che la memorizzazione nella cache i valori di campo in wrapper (cioè, evitando tutte le chiamate ToString e getta) probabilmente hanno più di un impatto sulle prestazioni.

Poi, una volta che si sta caching quei valori probabilmente si vorranno mantenere le istanze di Wrapper piuttosto che di frequente li ricreare.

Answer 5

Supponendo che sei davvero preoccupati per (hey, succede) e poi l'involucro sottostante per sé potrebbe essere migliorata. Stai facendo le ricerche sul campo da stringa. Se avete intenzione di effettuare la chiamata molto con lo stesso campo impostato nella fila, in realtà è più veloce per memorizzare nella cache gli ordinali e guardare in alto per ordinale.

Naturalmente questo è solo se si ha realmente, realmente bisogno di preoccuparsi per le prestazioni, ei casi in cui questo sarebbe fare la differenza sono abbastanza raro (anche se in dispositivi embedded non è così raro come sul desktop).