2009-11-16 3 views
1

Je pose cette question avec la performance comme préoccupation principale. Mais j'aimerais connaître d'autres avantages/inconvénients possibles pour les deux approches. La question est: Puisque les propriétés sont converties en méthodes dans IL, pourrait-il y avoir une pénalité de performance significative si les propriétés sont appelées au lieu d'accéder directement aux champs (à l'intérieur de la classe)?Accéder directement à la variable membre par l'intermédiaire de la propriété

Je suis en train de concevoir une classe de transformation (PersonalizationConstructor) dont le but est de "construire une entité de domaine" à partir d'IDataReader.

Je pense accepter IDataReader dans le constructeur de cette classe (PersonalizationConstructor) et avoir des propriétés virtuelles protégées pour renvoyer des données de l'ensemble d'enregistrements IDataReader; comme:

protected virtual string ProductFilterCriteria 
{ 
    get; 
    set; 
} 

Je pourrais avoir plus de 15 propriétés dans une classe pour cette implémentation. De cette façon, une propriété peut être surchargée pour vérifier si l'ensemble d'enregistrements a un champ "XXX" avant d'accéder à partir de l'ensemble d'enregistrements (je ne veux pas avoir cette vérification comme implémentation par défaut pour tous).

Est-il bon d'avoir plus de 15 propriétés virtuelles dans une classe pour implémenter le cas ci-dessus?


Veuillez ne pas trop vous concentrer sur IDataReader. Ma principale préoccupation est:

Comme les propriétés sont converties en méthodes IL, pourrait-il y avoir des performances importantes pénalité si propriétés sont appelées au lieu d'accéder à des champs directement (à partir de la classe)?

Je tiendrions quelque chose comme ceci:

class MainSite 
{ 
    protected virtual string ProductFilterCriteria 
    { 
     get 
     {   
      return _source["ProductFilterCriteria"]; 
     } 
    } 

    protected virtual string Abc 
    { 
     get 
     { 
      return _source["Abc"]; 
     } 
    } 

    protected virtual string Def 
    { 
     get 
     { 
      return _source["Def"]; 
     } 
    } 

    ..... many properties 
} 

class VirtualSite : MainSite 
{ 
    protected override string ProductFilterCriteria 
    { 
     get 
     { 
      return null; 
     } 
    } 
} 

Répondre

1

Définition ou la récupération d'une propriété qui est mis en œuvre avec la syntaxe de la propriété C# 3.0, ou ancien style soutenu avec un champ, peut (mais ne sera pas nécessairement) être optimisé par le JIT. Cela signifie que toute optimisation à cet égard ne sera pas mesurable ou pourrait même être contre-productive. Vous parlez de propriétés qui prennent un type de classe (par opposition à un type primitif comme int de float). Les frais généraux de ces classes (ctor) ou le temps passé à faire des choses totalement différentes (vous mentionnez IDataReader qui, je suppose, lit les données, ce qui est cher) sont tellement plus grands que les 1 ou 2 μ-ops que vous pourriez en changer. propriété à champ. Ce que je comprends: c'est comme 0,001% de profit, si même. En d'autres termes: bien que dans des situations très rares où vous êtes dans une boucle interne et que vous devez en extraire toutes les microsecondes, vous pouvez reconsidérer ce choix. Dans toutes les autres situations: utilisez des gettors/settors.

PS: lire l'autre réponse à ce q. me fait penser que j'ai peut-être mal compris. Si oui, laissez un commentaire

EDIT: Jon S. mentionne que les propriétés virtuelles ne sont pas optimisées, ce qui est correct.Mais l'histoire en ligne sur le bénéfice mineur reste peu importe

+0

Dans ce cas, il s'agit de propriétés virtuelles, ce qui signifie qu'elles ne peuvent pas être optimisées (sauf dans le cas où le type est connu pour sceller la propriété). –

+0

@Jon: merci, vous avez absolument raison. Mais même dans ce cas, le gain de performance lié au passage d'une propriété à l'autre est négligeable dans presque tous les scénarios. – Abel

1

Vous voulez probablement accepter un IDataRecord plutôt que IDataReader, puisque c'est le « type de base » qui décrit la partie d'un DataReader que vous soucier.

Sinon, je voudrais simplement utiliser les propriétés. Ça ira. Je ne les marquerais pas "virtuels". Les chances sont que ce type n'est pas vraiment destiné à être hérité, et si c'est le cas, ces propriétés ne devraient probablement pas être touchées.

2

Comme toujours, avant de prendre des décisions de conception basées sur les performances - mesurez-le!

En supposant que les données proviennent d'une base de données relationnelle, I fortement suspecter que la requête elle-même (et les conversions associées, réseau IO etc) va dominer les performances. Le JIT ne pourra pas intégrer les appels de propriétés virtual, mais si la raison de l'utilisation des propriétés virtuelles est que différentes implémentations peuvent avoir besoin de faire différentes choses, vous n'avez vraiment pas la possibilité d'utiliser accès direct au champ de toute façon. Je ne voudrais pas dire si votre design est bon ou pas - nous n'avons pas vraiment assez d'informations - mais si vous pensez que c'est la manière la plus lisible d'implémenter ce dont vous avez besoin, alors construisez un prototype et mesurez-le performance avant de dévier de cette conception.

Questions connexes