10
votes

Pourquoi casser plus vite que la réflexion dans .NET?

J'ai un gestionnaire d'événements qui doit déterminer un type et exécuter du code s'il correspond à un type spécifique. À l'origine, nous le jetons à un objet et si ce n'était pas NULL, nous avons exécuté le code, pour accélérer, j'ai utilisé la réflexion et cela le ralentit effectivement et je ne comprends pas pourquoi.

Voici un échantillon de code xxx

et c'est la sortie de trace que je reçois xxx

Ce n'est pas beaucoup, mais si nous devions le faire beaucoup avec le temps, il pourrait s'ajoindre.


4 commentaires

Tout pourrait ajouter au fil du temps. Sauf si vous avez des preuves que ce est en fait additionner au fil du temps, ne vous inquiétez pas à ce sujet.


C'est plus sur les meilleures pratiques, si la coulée est plus rapide, je devrais utiliser le casting au lieu de la réflexion


Cette logique ne suit pas du tout. Si la coulée est correcte, vous devriez utiliser la coulée au lieu de réflexion. L'exactitude est plus importante que la vitesse.


@ Scientifique dans cette affaire est le facteur déterminant et de la consensus générale à l'aide de la coulée est la meilleure pratique, ma question était davantage dans ce casting dans ce cas, est-ce que c'est toujours le cas, ce qui est considéré comme la meilleure pratique


6 Réponses :


15
votes

La réflexion est lente car vous interrogez les métadonnées de l'Assemblée, tandis que la coulée modifie simplement le type de l'objet que vous référenciez.

Les métadonnées de l'Assemblée sont un magasin utile d'informations, mais que les informations sont mieux utilisées chez temps de compilation plutôt qu'à l'exécution. Cette métadonnée est utilisée par le compilateur pour la vérification de type statique (entre autres). Vous utilisez cette même métadonnées pour rechercher des informations de type à l'heure d'exécution (qui va bien si vous n'avez pas d'autre choix), ce qui est nettement plus lent que le casting.


0 commentaires

3
votes

La réflexion doit aller à l'exécution et déterminer quelles propriétés, etc. L'objet a à l'exécution. Le casting indique à l'application qu'il devrait s'attendre à ce que un objet ait X propriétés et devrait fonctionner d'une certaine manière.


0 commentaires

2
votes

Casting indique l'exécution que vous "savez" le type d'un objet particulier. Bien que vous puissiez vous tromper, le temps d'exécution vous croit et ne prend pas le temps supplémentaire nécessaire pour vérifier les métadonnées de l'Assemblée.


0 commentaires

1
votes

Pourquoi n'utilisez-vous pas le Opérateur ? Je pense que c'est plus lisible car vous n'avez pas la fonte explicite, puis vérifiez. Il vérifie simplement que la variable est du type correct.

if (e.Item is GridDataItem)
{
    bool isWatch = Convert.ToBoolean(e.Item.OwnerTableView.DataKeyValues[e.Item.ItemIndex]["IsWatch"]);
    if (isWatch)
    {
        e.Item.Style["Font-Weight"] = "bold";
    }
}


7 commentaires

En fait, "est" fait une coulée sous les couvertures.


Mon point était que cela simplifie le code (le rendant plus lisible), pas que cela fait quelque chose de fondamentalement différent. Je vais clarifier.


C'est en fait plus lent à partir de 1.5268064962406 1.311905 Mise finale 1.52701457443609 0.000208 Démarrage 1.59114193383459 0.064127 Fin 1.59120311278195 0.000061


N'est-il pas vrai que "est" et "comme" n'utilise pas d'opérateurs de conversion alors que la coulée fait? Si tel est le cas, une distribution n'est pas vraiment faite "sous les couvertures" pour "IS".


@Bob qui semble étrange car selon la référence C #, comme c'est équivalent à: l'expression est de type? (type) Expression: (type) null. Voir les remarques sur msdn.microsoft.com/en-us/library/cscsdfbt. ASPX .


... Peut-être que la première référence nécessite de l'obtenir de la mémoire et la seconde l'utilise du cache. Avez-vous essayé dans l'ordre inverse?


Pour la rapidité, tout ce que je sais, c'est ce que les données disent, et si vous comparez les temps en utilisant "est" est plus proche de l'utilisation de la réflexion



0
votes

Eh bien, je suppose qu'une réponse courte à la partie la meilleure pratique serait de ne jamais utiliser la réflexion si vous pouvez obtenir le même résultat avec le code régulier.

Lors de l'optimisation du code, il est généralement une bonne idée d'estimer lorsque l'optimisation du temps passé entraînera le plus grand gain de performance. Rimplifier les opérateurs de manière native dans la langue est rarement au sommet de cette liste


0 commentaires

1
votes

Les moules peuvent être effectuées sous forme de comparaisons entière dans l'exécution, mais la réflexion implique des appels de méthode complète.


0 commentaires