C # question de la performance

Question

quandry est - lequel des deux méthode suivante fonctionne mieux
Objectif - obtenir un objet de type Wrapper (défini ci-dessous)
critères - vitesse sur le stockage
non. des dossiers - environ 1000- environ 2000, max à propos 6K
Choix - Créer un objet à la volée ou faire une recherche dans un dictionnaire
La vitesse d'exécution - appelée x fois par seconde

NB - je dois fournir le code de travail d'abord et ensuite pour l'optimisation donc si des théoriciens peuvent donner un aperçu derrière l'info scène, ça va aider avant de passer à l'épreuve de la performance réelle peut-être par NEM jeu.

Définitions -

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;  

Méthode 1

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

Méthode 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

La première serait plus rapide, car il ne fait pas réellement une recherche, il fait juste une allocation simple et une affectation.

Les deux segments de code ne sont pas presque équivalent. En fonction cependant, parce que la méthode 1 pourrait créer beaucoup de doublons.

Answer 2

1. Ne jamais optimiser sans profilage d'abord.
2. Jamais profil à moins que le code ne correspond pas aux spécifications / attentes.
3. Si vous avez besoin de profiler ce code, écrire dans les deux sens et référence avec votre charge prévue.

EDIT: J'essaie de favoriser ce qui suit sur l'optimisation des performances est inacceptable à moins que:

• Simplicité
• Lisibilité
• maintenabilité
• testabilité

J'ai (récemment) vu le code hautement optimisé qui était très difficile à déboguer. Je refactorisé pour simplifier, puis a effectué des tests de performance. Le rendement était inacceptable, donc je ne profile, a trouvé les goulots d'étranglement et optimisé que ceux-ci. Je re-couru les tests de performance, et le nouveau code était comparable à la version très optimisée. Et il est maintenant beaucoup plus facile à maintenir.

Answer 3

Voici un libre outil de profilage .

Answer 4

Sans test en fait j'attendre à ce que la mise en cache des valeurs de champ dans Wrapper (qui est, en évitant tous les appels ToString et des moulages) aurait probablement plus d'impact sur les performances.

Ensuite, une fois que vous êtes en mémoire cache les valeurs que vous voudrez probablement garder les instances de Wrapper autour plutôt que de les recréer fréquemment.

Answer 5

En supposant que vous êtes vraiment inquiet par (hey, il arrive), votre emballage sous-jacent lui-même pourrait être amélioré. Vous faites des recherches sur le terrain par chaîne. Si vous allez faire l'appel beaucoup avec le même champ situé dans la ligne, il est en fait plus rapide à mettre en cache les ordinaux et rechercher par ordinal.

Bien sûr, cela est que si vous avez vraiment besoin de vous soucier de la performance, et les cas où cela ferait une différence sont assez rares (bien que dans les systèmes embarqués, il est pas aussi rare sur le bureau).