[C#] cast vs conversion explicite, optimisation

hello,

j'aimerais savoir quelle est la manière la plus performante pour caster un objet d'un type vers un autre sachant que le cast n'échouera jamais.

voici typiquement ce que je fais sur list qui est une instance de List<T>

Code:

---

1 2 3 4 5

lock (((ICollection)list).SyncRoot) { ... }

---

ou

Code:

---

1 2 3 4 5

lock ((list as ICollection).SyncRoot) { ... }

---

j'aurais eu tendance à dire que l'opérateur de conversion explicite (le C-style cast) était plus rapide que le dynamic_cast, malheureusement, un message sur un forum datant de 2003 disait le contraire ; cependant, ce message concernait .net 1...

Qu'en est-il pour .net >= 2 ?

merci d'avance

personnellement, j'aurais tendance a dire qu'on s'en moque...

ca ressemble a de la micro-optimisation, a vue de nez, a moins d'appeler 1 000 000 de fois le lock, tu ne gagneras rien a faire l'un ou l'autre...

enfin, c'est mon avis a moi, et je le partage avec moi-meme...

Salut,

il y a apperement quelques differences detaillees dans cet article: (en anglais)

http://gen5.info/q/2008/06/13/prefix...-casting-in-c/

A+

Citation:

---

Envoyé par pvialatte

personnellement, j'aurais tendance a dire qu'on s'en moque...

---

Je préfère connaitre les mécanismes du langage correctement.

Citation:

---

Envoyé par pvialatte

ca ressemble a de la micro-optimisation, a vue de nez, a moins d'appeler 1 000 000 de fois le lock, tu ne gagneras rien a faire l'un ou l'autre...

---

Oui et non, c'est une zone du code qui pourrait potentiellement être invoquée 1 000 000 de fois.

Citation:

---

Envoyé par toxycyty

Salut,

il y a apperement quelques differences detaillees dans cet article: (en anglais)

http://gen5.info/q/2008/06/13/prefix...-casting-in-c/

A+

---

je suis bon pour changer tous mes casts, le dynamic_cast étant 5 fois plus rapide que la conversion explicite.
Encore merci pour vos réponses et cet article qui met fin à cette discussion.

yohan

Citation:

---

Envoyé par sneakysponge

je suis bon pour changer tous mes casts, le dynamic_cast étant 5 fois plus rapide que la conversion explicite.
Encore merci pour vos réponses et cet article qui met fin à cette discussion.

---

Nyet, pas d'accord, ce que je soulevais rete valide...

Si tu lis l'article, tu vois que sur 29 millions de cast, tu as une différence de 600 millisecondes...si c'est ce qui te ralentit le plus, tu as une sacrée chance :mouarf:

Ça reste de la micro-optimisation, j'insiste :aie:

En plus, j'avais lu en travers, mais, dans ton exemple, si ta liste implémente ICollection, le cast est, en plus, inutile...vu que justement, l'intérêt d'utiliser une interface, c'est de s'assurer que les classes implémentant l'interface remplissent le contrat défini par ton interface...ou sinon, j'ai loupe un train...

Citation:

---

Je préfère connaitre les mécanismes du langage correctement.

---

Pour ca, par contre, ok, mais la difference est plus "fonctionelle" que une question de perfs...et en plus, l'article cite sur gen5 a a peu pres cette conclusion, utiliser les cast prefixes...

En terme de bonne pratique, les exceptions doivent être remontées le plus tôt possible

Citation:

---

Envoyé par pvialatte

En plus, j'avais lu en travers, mais, dans ton exemple, si ta liste implémente ICollection, le cast est, en plus, inutile...vu que justement, l'intérêt d'utiliser une interface, c'est de s'assurer que les classes implémentant l'interface remplissent le contrat défini par ton interface...ou sinon, j'ai loupe un train...

---

list est une instance de List<T>, par réflexion, tu verras que List<T> implémente explicitement ICollection, donc le seul moyen d'accéder à son SyncRoot, sauf erreur de ma part, c'est le cast.

Citation:

---

Envoyé par pvialatte

En plus, j'avais lu en travers, mais, dans ton exemple, si ta liste implémente ICollection, le cast est, en plus, inutile...vu que justement, l'intérêt d'utiliser une interface, c'est de s'assurer que les classes implémentant l'interface remplissent le contrat défini par ton interface...ou sinon, j'ai loupe un train...

---

Citation:

---

Envoyé par sneakysponge

list est une instance de List<T>, par réflexion, tu verras que List<T> implémente explicitement ICollection, donc le seul moyen d'accéder à son SyncRoot, sauf erreur de ma part, c'est le cast.

---

Vous avez tous les deux raison :

- Si List<T> implémente ICollection, elle devrait présenter la propriété SyncRoot. Mais ce n'est pas le cas, l'implémentation de ICollection par List<T> cache cette propriété.
Ne me demandez pas pourquoi, je me pose moi-même déjà cette question !
- Dans le cas de List<T>, comme cette propriété est cachée par l'implémentation, il faut passer par un cast.


@sneakysponge : si ta liste ne manipule que des string, je te propose StringCollection qui présente publiquement la propriété SyncRoot (il n'y aurait donc pas besoin de caster dans ce cas).

arf, le boulet, comme je te voyais caster sur une ICollection, j'avais pense a une arraylist...

Ceci dit, je crois me rappeler que microsoft avait une raison pour ne pas utiliser SyncRoot dans le framework v2.0....faudra que je cherche ;)

Citation:

---

Envoyé par pvialatte

Ceci dit, je crois me rappeler que microsoft avait une raison pour ne pas utiliser SyncRoot dans le framework v2.0....faudra que je cherche ;)

---

Ca m'intéresse !

J'ai trouve :D

http://blogs.msdn.com/bclteam/archiv...15/396399.aspx

Le but étant de laisser aux développeurs la possibilité de gérer leur propre synchronisation a un niveau plus élevé...