Avant Linq, nous utilisions généralement la méthode suivante pour déterminer si une collection n’est pas vide, c’est-à-dire si une collection contient des éléments :
En utilisant les attributs Longueur ou Compte, il n’y a aucun problème avec l’écriture ci-dessus.
Mais à l’époque de Linq, la méthode d’extension Enumerable.Count « unifiait » les propriétés Length et Count, ce qui aboutit à la manière suivante d’écrire pour juger la non-nullité :
Cette écriture est correcte et fonctionne bien, mais elle peut causer de très sérieux problèmes de performance.
Notez que c’est possible, pas nécessairement, et si la méthode ci-dessus est intégrée sous forme de <T>tableau, de liste ou de collection<T>, il n’y aura aucun problème.
Alors, quand quelque chose va-t-il mal tourner ? Voyons les méthodes suivantes :
Lorsqu’on l’appelle :
La vitesse d’exécution sera assez lente, et il a fallu environ 70 secondes à mon ordinateur pour exécuter le code source. Count() > 0。
Si vous l’analysez, vous verrez que le rendement i dans la ligne 5 du code GetNums s’exécute int. MaxValue, est-ce nécessaire ?
En fait, tant que nous retournons un élément, nous pouvons conclure que l’ensemble est non vide, et qu’il n’est pas nécessaire de retourner tous les éléments.
Alors, comment juger ? Nous pouvons utiliser la méthode d’extension Enumerable.Any :
Modifiez la méthode SomeAction comme suit :
Répétez et vous constaterez que le temps d’exécution est négligeable.
Pour résumer, Count() > 0 aura inévitablement des problèmes de performance lorsqu’il rencontrera un retour de main.
|
Publié sur 12/10/2017 13:25:01
|
|
|
|
