Discussion :

[marcusien]

Bonjour,

Une question qui peut paraître sommaire au premier abord mais je voulais récolter quelques avis.

J'ai un Dictionary<Guid, MonEnum> que j'instancie au clic d'un bouton ("Ajouter des données")

Code C# :

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

1
2
3
4
5
6
public enum MonEnum
{
    Fixe,
    Temporaire
}

J'ai deux autres boutons :

• Valider les changements
• Annuler

Mon interface contient une grille avec des cases à cocher que l'utilisateur peut cocher. Le dictionnaire en question contient une liste d'éléments qui seront précochés dans cette grille.

Sur le bouton valider, je vais traiter toutes les données
Sur le bouton annuler, je vais vouloir annuler mes changements

Mon "problème" est que je ne sais pas si je dois plutôt:

• Supprimer les éléments de mon dictionnaire qui ont pour valeur : "Temporaire" et ainsi conserver nos éléments dits "Fixe"
• Supprimer la collection (en l'affectant à null)

En sachant que ce dictionnaire, lors du prochain clic sur "ajouter des données" devra être rechargé si on a auparavant supprimé les données dites "Temporaire", alors que si on a juste supprimé les éléments temporaires lors du clic sur "Annuler", on ne devra pas lui rajouter nos éléments dits "Fixe"

La chose à prendre en compte est que vider la collection m'oblige à la parcourir par un "for reverse" et supprimer les éléments qui ne correspondent pas à mes critères, alors que de l'autre côté, si je la supprime purement et simplement, je n'aurai qu'à la réinstancier et ajouter à nouveau chacun de mes éléments "Fixe".

Merci du coup de main, j'espère ne pas avoir trop embrouillé

Laurent

[kheironn]

Je ne sais pas comment tu le remplis ton dico, mais peut-être faudrait-il voir de ce côté.
Si c'est fixe, tu n'ajoutes pas l'élément à ta collection.

sinon, sans mettre à null, tu peut vider ton dico avec Clear().

[DonQuiche]

Bonjour.

Avant toute chose, y a t-il actuellement un problème de performances ou est-ce, comme je le présume, de l'optimisation prématurée ? Si oui, la meilleure solution est la plus limpide, en l’occurrence l'utilisation de Clear().

Maintenant, imaginons qu'il y ait un pb de performance, voici les implications de chaque cas :

• Mise à null. Un dico est constitué d'un tableau de petits tableaux. Le GC devra d'abord libérer tout ça (facile) et ensuite faire le ménage pour éviter le pourrissement de l'espace mémoire (lent et, dans certaines configurations ASP ou pour des processus x86 sur IA64, cela suspend tous les threads). Ensuite, lorsqu'on réassignera, il faudra réallouer tous les tableaux, les redimensionner plusieurs fois au fur et à mesure que l'on ajoutera de nouveaux éléments, donc créer et détruire plein d'instance, etc. Autant le dire : c'est du lourd et on peut provoquer un dépassement mémoire si les cycles vidage/remplissage se succèdent très rapidement (les grands tableaux sont rarement passés en revue par le GC). Seul avantage : si à l'avenir on devait ajouter bien moins d'éléments on ne gaspillerait pas de mémoire et les futures opérations seraient accélérées (working set plus faible).
• Clear. On se contente de mettre à zéro un tableau (rapide) et toutes les structures existantes sont conservées. Du bonheur en barre, très rapide, et tout sera déjà prêt si l'on devait reremplir le dico. Désavantages : l'inverse des avantages de la solution précédente.
• Retrait manuel. Aucun avantage par rapport à Clear, que des désavantages. Maintenant, pour l'exercice intellectuel, si Clear n'avait pas été dispo, c'est une solution plus lente que la mise à null à l'étape du vidage mais, comme pour Clear, elle maintient les structures en place pour le prochain remplissage, accélérant celui-ci. Et on évite au passage les problèmes de pénurie de mémoire mentionnés avec la mise à null.

[marcusien]

Merci pour votre avis.

Je n'avais pas mis le Clear dans mes propositions car pour moi c'était quelque chose qui se situait entre mes deux autres propositions. Car comme j'ai expliqué, soit je n'enlève de ma collection que les éléments que je ne souhaite pas garder (ceux dont l'enum est "temporaire") soit je vide tout et du coup il faudra que je re-remplisse ma collection avec les éléments "fixe".

Pour ma part, n'ayant jamais vraiment étudié le fonctionnement du Clear() (méthode que j'ai utilisé néanmoins de nombreuses fois en tant que développeur évidemment), je ne pensais pas qu'il y avait de telles différences entre un Clear() et une mise à NULL suivi d'une instanciation.

Donc merci beaucoup à vous deux et notamment à DonQuiche pour ces éléments pointus.
Du coup je pense que le Clear() puis rechargement de mes éléments "Fixe" parait être le meilleur compromis.

P.S : pour répondre à la question de base, ce n'est pas un souci de performance constaté, c'est juste que de mon point de vue, il ne faut pas attendre que les problèmes de performances se fassent ressentir avant de réfléchir à "comment optimiser les performances de mon application"

[DonQuiche]

P.S : pour répondre à la question de base, ce n'est pas un souci de performance constaté, c'est juste que de mon point de vue, il ne faut pas attendre que les problèmes de performances se fassent ressentir avant de réfléchir à "comment optimiser les performances de mon application"

Dans ce cas, je t'invite à être extrêmement prudent. Ajouter de petites optimisations partout ne rend pas un logiciel plus rapide (parce que, même mal optimisées, ces parties du code représentent moins de 0.1% du temps CPU) mais est très efficace pour pourrir un code.

Le seul cas où l'optimisation prématurée peut se justifier, c'est lorsque l'on sait à l'avance que cette partie du code va être extrêmement lourde, qu'elle va représenter une grosse part du temps CPU. Et, même là, il ne faut pas trop en faire dès le début alors qu'on n'a pas encore de mesures sur lesquelles s'appuyer, puisque même pour un développeur chevronné il est parfois difficile de garantir avec certitude ce qui sera le plus rapide.

Le reste du temps, seules la lisibilité, la maintenabilité et la concision comptent.

[marcusien]

Ce sont des points de vues personnels, mais même si effectivement je privilégie d'abord la lecture du code à l'optimisation pure et dure, je vois quand même que quand on écrit du code on essaie également d'être optimisé dès le début en écrivant. Beaucoup de choses s'acquièrent avec l'expérience et on arrive à faire du code optimisé tout en l'écrivant.

Par contre, évidemment, je ne parle pas d'optimisation poussée. Par exemple pour ma part je vais plutôt utiliser des lambda expression ou des foreach (quitte à placer un if (...) continue; ou if (...) break plutôt que des while qui sont bien moins lisible à mon sens lorsque l'on parcourt une collection.

Tout est affaire de jaugeage, car quand on code en C# en général c'est qu'on souhaite se placer à haut niveau. Pour avoir une application réellement optimisée à ce moment là on va sur des langages plus bas niveau.

Bref, merci quand même pour ces conseils, je garderai tout de même ça à l'esprit.