? : Opérateur Vs. performance de l'instruction If

Question

J'ai essayé d'optimiser mon code pour le rendre un peu plus concis et lisible et j'espérais que cela n'entraînerait pas une baisse des performances. Je pense que mes modifications ont pu ralentir mon application, mais c'est peut-être juste dans ma tête. Y a-t-il une différence de performance entre :

Command.Parameters["@EMAIL"].Value = email ?? String.Empty;

et

Command.Parameters["@EMAIL"].Value = (email == null) ? String.Empty: email;

et

if (email == null)
{
    Command.Parameters["@EMAIL"].Value = String.Empty
}
else
{
    Command.Parameters["@EMAIL"].Value = email
}

Pour des raisons de lisibilité, je préférerais l'opérateur de coalescence des nuls, mais je ne voulais pas que cela affecte les performances.

Answer 1

Vous essayez de micro-optimiser ici, et c'est généralement un grand non-non. À moins que vous n'ayez des analyses de performance qui vous montrent que c'est un problème, cela ne vaut même pas la peine de le changer.

Pour un usage général, la réponse correcte est celle qui est la plus facile à maintenir.

Pour l'anecdote, l'IL de l'opérateur de coalescence nul est le suivant :

L_0001: ldsfld string ConsoleApplication2.Program::myString
L_0006: dup 
L_0007: brtrue.s L_000f
L_0009: pop 
L_000a: ldsfld string [mscorlib]System.String::Empty
L_000f: stloc.0 

Et le VA pour l'échange est :

L_0001: ldsfld string ConsoleApplication2.Program::myString
L_0006: brfalse.s L_000f
L_0008: ldsfld string ConsoleApplication2.Program::myString
L_000d: br.s L_0014
L_000f: ldsfld string [mscorlib]System.String::Empty
L_0014: stloc.0 

Pour le opérateur de coalescence nul si la valeur est null alors six des instructions sont exécutées, alors qu'avec le paramètre switch quatre opérations sont effectuées.

Dans le cas d'un non null l'opérateur de coalescence nul effectue quatre opérations contre cinq.

Bien entendu, cela suppose que toutes les opérations de VA prennent le même temps, ce qui n'est pas le cas.

Quoi qu'il en soit, j'espère que vous pouvez voir comment l'optimisation à cette échelle micro peut commencer à diminuer les rendements assez rapidement.

Cela étant dit, en fin de compte, dans la plupart des cas, ce qui est le plus facile à lire et à entretenir dans ce cas est la bonne réponse.

Si vous trouvez que vous faites cela à une échelle où cela s'avère inefficace (et ces cas sont rares), vous devez alors mesurer pour voir quelle est la meilleure performance et ensuite faire cette optimisation spécifique.

Answer 2

À mon avis, optimisez pour la lisibilité et la compréhension - tout gain de performance à l'exécution sera probablement minime par rapport au temps qu'il vous faudra dans le monde réel pour revenir à ce code dans quelques mois et essayer de comprendre ce que vous faisiez au départ.

Answer 3

Je pense que mes changements ont pu ralentir mon application, mais ça pourrait juste dans ma tête.

A moins que vous ne soyez mesure performance, c'est tout dans votre tête et des spéculations oiseuses.

(Je ne m'en prends pas à vous en particulier, mais il est tellement décevant de voir les questions sur les micro-optimisations des performances (ainsi que de nombreuses réponses) qui ne contiennent pas le mot "mesure").

Answer 4

Je pense qu'il n'y aura pas de différence de performance.

A côté de cela, je me demande pourquoi vous auriez le souci de favoriser une déclaration plutôt que l'autre dans ce cas ? Je veux dire que l'impact sur les performances (s'il y en a un) serait minime. À mon avis, il s'agirait d'une sorte de micro-optimisation, et cela ne vaudrait pas la peine d'en faire l'effort.
Je choisirais l'énoncé le plus lisible, le plus clair, et je ne me préoccuperais pas des performances puisque leur influence serait minime (dans ce cas).

Answer 5

Presque aucune différence de performance significative dans ce cas.

Lorsque la différence de performance est négligeable, il s'agit d'une question d'efficacité. code lisible .