Discussion :

[ZaaN]

je voulais savoir quel code est le plus performant en terme de temps. Et bien evideamment, m'expliquer pourquoi ...

merci d'avance

Version A

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
foreach (var item in _Items.Where(Item => Item.BoolProp == true))
{
    item.BoolProp = false;
}

Version B

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
foreach (var item in _Items)
{
    item.BoolProp = false;
}

[theMonz31]

salut

aucune idée

Par contre, tu mets un Stopwatch avant et après pour mesurer et tu compares les deux résultats

[Guulh]

A moins que tes collections ne contiennent des milliers / des millions d'objet, ou que tu fasse un traitement un peu lourd dans le set de ta propriété (du style un NotifyPropertyChanged), l'éventuelle petzouille de différence de perf ne vaut pas la complexité de code que représente ta première solution.

Et code complexe => code lourd à maintenir

Mais même, admettons : à vue de nez, je dirais qu'une comparaison de booléens n'est pas plus rapide qu'une affectation de booléen. Dans le cas 2, on fait N affectations ; dans le cas 1, on fait N comparaisons et n affectations. (où N est ton nb d'élements dans la liste, et n le nombre d'éléments ayant BoolProp = true)

[karlus]

Dans la premiére version tu vas parcourir l'ensemble de la collection. Puis faire à nouveau un parcours de la liste résultante. Donc je pense que le deuxiéme solution sera ( quasiment ) toujours la plus rapide.

Il semblerait même qu'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(int i = 0 ; i < list.Count; i++)

est plus rapide que le foreach

Évidemment coté lisibilité la question ne se pose pas ...

[tomlev]

Dans la premiére version tu vas parcourir l'ensemble de la collection. Puis faire à nouveau un parcours de la liste résultante.

Non, la collection ne sera parcourue qu'une seule fois. Mais dans les 2 cas, elle sera parcourue en entier donc je ne pense pas qu'il y ait une différence notable entre les 2 solutions.
Par contre, je suppose qu'ici _Items est une simple collection d'objets ? Parce que si c'est un ensemble d'entités Linq to SQL ou EF par exemple, et que la colonne est indexée, la 1e solution sera a priori plus rapide

[ZaaN]

A moins que tes collections ne contiennent des milliers / des millions d'objet, ou que tu fasse un traitement un peu lourd dans le set de ta propriété (du style un NotifyPropertyChanged), l'éventuelle petzouille de différence de perf ne vaut pas la complexité de code que représente ta première solution.

Mais même, admettons : à vue de nez, je dirais qu'une comparaison de booléens n'est pas plus rapide qu'une affectation de booléen. Dans le cas 2, on fait N affectations ; dans le cas 1, on fait N comparaisons et n affectations. (où N est ton nb d'élements dans la liste, et n le nombre d'éléments ayant BoolProp = true)

Merci pour vos point de vue.

Pour ma part je pense que la complexité du set et du get de la propriété vont totalement decidé quel version je vais implementer.

• Dans le cas ou la propriété est une simple variable, la Version 2 est plus adaptée.
• Dans le cas ou le set est plus lent que le get, je vais prendre la Version 2
• Dans le cas ou le set est plus rapide que le get, la version 1

[Greybird]

Merci pour vos point de vue.

Pour ma part je pense que la complexité du set et du get de la propriété vont totalement decidé quel version je vais implémenter.

• Dans le cas ou la propriété est une simple variable, la Version 2 est plus adaptée.
• Dans le cas ou le set est plus lent que le get, je vais prendre la Version 2
• Dans le cas ou le set est plus rapide que le get, la version 1

La règle d'or en terme d'optimisation de performance, c'est de mesurer la performance de chaque solution avec des jeux de données représentant des cas réels, et de statuer sur la solution à apporter par rapport aux résultats. Seuls les résultats te fournissent une idée de la performance d'un code. Les suppositions peuvent se montrer à des années lumière de la réalité, même sur des cas relativement simples.

Et bien sûr, il est utile de reproduire ces tests régulièrement au fur et à mesure que le projet avance pour s'assurer qu'on utilise toujours la bonne solution. Ça peut même être instrumenté via des tests unitaires au besoin.

En effet, le get et le set ne sont techniquement pas les seuls en cause dans le code produit. Tu as les mécanismes d'énumération par exemple, qui vont contribuer à la performance, au delà du get et du set.

Une dernière chose : ces tests de performance doivent être faits avec le code compilé en mode Release, car le mode Debug désactive un paquet d'optimisation et ajoute des instructions nécessaires aux débuggers pour leur permettre de se brancher, et bien évidemment, tout cela influe sur les performances.