[c#] methodes statique Avantages/inconvénients

Bonjour


Je vais prendre un exemple d'une application web et pour chaque point je vais détaillé
cet exemple de code vas nous servir de base.

Code:

---

1 2 3 4 5 6 7

public static datatable GetData(int idData) { MY_CLASS my_class = new MY_CLASS(idDATA); return my_class.Load();   }

---

1- Performance d'exécution.
comment seront les performance de traitement/appel de plusieurs méthode successif dans le cas de plusieurs appel simultanée (Couche d'accès aux donnée d'une application WEB)
Plusieurs appel simultanée de notre exemple cité ci-dessus


2- Gestion de mémoire
La gestion en mémoire de tout les données instancié à l'intérieur d'une méthode statique dans le cas de plusieurs appel simultanée (Couche d'accès aux donnée d'une application WEB)
exemple cite ci-dessus



3- Règles de choix entre Statique ou non.
Est ce que j'aurais du choisir une méthode statique ou une méthode normale.


D'avance merci

Salut,

alors pour reprendre ton exemple :

1-

En terme de performances, la staticité de la methode de te fait sauter le premiere argument implicite des methodes d'instances à savoir le this. Cela fait un chargement d'int sur la pile (ou de la taille du pointeur natif de la plate forme) en moins coté appelant.

Concernant la dualité resolution de la methode runtime vs compilation, à moins d'appeler la dite methode 10 000 fois par seconde, la difference est totalement negligeable (et dans le cas precis que tu as donné, ce n'est pas la staticité ou non de la methode qui va fatiguer ton GC, mais plutot le fait de créer des classes locales à gogo).

2-

La gestion de la memoire est strictement identique que les variables ou membres soient instanciés dans une methode statique ou d'instance. Ici tu instancies une classe, la memoire sera alloué dans le tas managé (potentiellement le tas à "gros objet" (LOH) si la class a une taille de 85 kbytes et plus). Mais encore une fois, la staticité ou non de la class, ne changera pas les regles d'instanciation standard en vigueur.

3-

La regle est toujours la meme, si tu as besoin de données d'une instance == pas static, si ta methode se suffit à elle meme == static.

Bonjour

Ton argumentation parait logique.
Seul HIC. sur quoi tu te base ? et est ce que tu as des références/documentations sérieuse sur ce que tu vient d'avancer ?

D'avance merci

Je les ai donné plus haut ...

Citation:

---

ni les quelques livres parlant de la CLR (Essentials .Net : The CLR; Expert .Net 2.0 IL Assembler) n'en parle.

---

D'ailleurs, en faisant le tour des blogers des differentes teams perf et/ou CLR, nul n'est abordé des problematiques d'optimisation aussi fines (et je pense qu'il y a une raison ...).

Bref, si tu en viens à ce genre de considerations en terme d'optimisation (qui est de l'ordre du tick ...), la premiere question serait de se demander si .Net est un choix pertinent (on a deja vu plus optimisé et optimisable comme langage). =)

Citation:

---

Envoyé par SirJulio

Bref, si tu en viens à ce genre de considerations en terme d'optimisation (qui est de l'ordre du tick ...), la premiere question serait de se demander si .Net est un choix pertinent (on a deja vu plus optimisé et optimisable comme langage). =)

---

Au dela de ca, si on veut optimiser l'acces aux donnees comme c'est le cas dans cet exemple, c'est plutot la requete SQL et la recuperation des donnes qui compte (parce qu'elle compte plein de process en o(n) voire o(n2 si on se debrouille mal), plutot qu'UN miserable appel de fonction, statique ou pas.

Optimiser, c'est bien, mais avant de mettre des ailerons a sa deudeuche, on fait une vidange.

Bref bartoumi, de mon point de vue, tu as suffisamment de marge de progression dans ta connaissance du C# a aborder avant de partir dans des considerations aussi pointues que non significatives. :)

Parce que la, pour refaire une analogie douteuse, c'est comme si tu disais "j'ai entendu que quand je peins ma mobylette en rose elle va plus vite. Avez-vous des sources qui le justifient ?" et que tu tombes sur des gens te disant "c'est insensible, mais peut etre que le colorant rose a une meilleure penetration dans l'air", ce a quoi tu reponds "Ah ? Prouvez-le !" Si c'est pas mentionne dans les docs, c'est qu'on n'a pas a s'en soucier.

Citation:

---

Envoyé par Guulh

Parce que la, pour refaire une analogie douteuse, c'est comme si tu disais "j'ai entendu que quand je peins ma mobylette en rose elle va plus vite. Avez-vous des sources qui le justifient ?" et que tu tombes sur des gens te disant "c'est insensible, mais peut etre que le colorant rose a une meilleure penetration dans l'air", ce a quoi tu reponds "Ah ? Prouvez-le !"

---

:mouarf2:

Citation:

---

Envoyé par Guulh

Parce que la, pour refaire une analogie douteuse, c'est comme si tu disais "j'ai entendu que quand je peins ma mobylette en rose elle va plus vite. Avez-vous des sources qui le justifient ?" et que tu tombes sur des gens te disant "c'est insensible, mais peut etre que le colorant rose a une meilleure penetration dans l'air", ce a quoi tu reponds "Ah ? Prouvez-le !" Si c'est pas mentionne dans les docs, c'est qu'on n'a pas a s'en soucier.

---

Ok, je viens de changer la couleur du mot clé static en rose bonbon, j'ai l'impression que ca marche mieux, j'ai gagné au moins 1 tick à l'appel ! Merci DVP.net !

=D

Salut,

Peut-être des pistes ici http://msdn.microsoft.com/en-us/library/ms973839.aspx, paragraphe "Appendix: Cost of Virtual Calls and Allocations".

A+

Citation:

---

Envoyé par Immobilis

Salut,

Peut-être des pistes ici http://msdn.microsoft.com/en-us/library/ms973839.aspx, paragraphe "Appendix: Cost of Virtual Calls and Allocations".

A+

---

Tiens, voilà du concret... :)

Je pensais aussi que ça ne faisait aucune différence en termes de perfs, mais apparemment ce n'est pas négligeable, puisque c'est 2.5 fois plus rapide en statique (si j'interprète bien les résultats).

Par contre, le fait que le test soit fait avec des méthodes vides fausse tout à mon avis : le temps d'exécution de la méthode est généralement nettement plus important que le temps qu'il faut pour l'appeler...

Mais bon, il faut relativiser...

Citation:

---

Envoyé par MSDN

One conclusion you can draw is that Virtual Function calls are about two times as expensive as regular calls when you're calling a method in a class. Bear in mind that calls are cheap to begin with, so I wouldn't remove all virtual calls. You should always use virtual methods when it makes sense to do so.

---

Instructif en tous cas... notamment le coup des méthodes de Object appelées sur un type valeur : si je comprends bien, c'est 36 fois plus long d'appeler ToString sur un type valeur que sur un type référence ??! J'avais jamais réalisé que boxing/unboxing était aussi couteux :roll:

http://msdn.microsoft.com/fr-fr/libr...wk(VS.80).aspx

Citation:

---

Envoyé par MSDN

Par rapport aux assignations simples, les conversions boxing et unboxing sont des processus qui coûtent cher en calcul. Lorsqu'un type valeur est converti (boxed), un objet entièrement nouveau doit être alloué et construit. À un degré moindre, le cast requis pour la conversion unboxing coûte également cher en calcul.

---

En effet, bonne ressource que voila !

@Tomlev :

je ne pense qu'il soit ici question de static ou non, mais plutot de methodes d'instances virtual (et peut etre overridée) ou non.

Le point de l'article etant de montrer que les structures, ça décoiffe si tu sais t'en servir, mais boxent (c'est pas bien donc) à gogo dans le cas contraire. Dans le cas present si tu appelles le toString d'une structure, la valeur doit etre boxée (ce qui implicitement revient à créer un objet, donc allouer dans le tas, recuperer le pointeur et le coller dans la pile etc ) pour que la methode puisse etre appelé (en l'occurence object::ToString()). C'est la meme problematique pour les implementations d'interface dans une structure, on peut le faire, mais ce n'est clairement pas une bonne idée (il va falloir boxer pour resoudre l'appel).

La seule mention de la staticité revient concernant les instanciations de classes, ou le bench met en exergue qu'il est legerement plus long d'instancier une classe qui possede des methodes virtuals qu'une classe n'ayant que des methodes statiques.

My 2 cents.

En revenant a des termes plus simple,
un appel a une fonction non statique a besoin que la classe soit instancie, et pas pour la fonction statique par definition, donc :
temps d'instanciation + temps d'appel a une fonction > temps d'appel a une fonction
non ? :aie:

Citation:

---

Envoyé par Tober

et pas pour la fonction statique par definition

---

Pas forcement (je n'en suis pas certain). FX Cop souligne que si une classe ne possede que des methodes statiques, il faut modifier la classe pour la rendre statique.
Dans le cas d'un mélange de type de methode, FX Cop stipule qu'un constructeur par défaut sera généré à la compilation. Y aura-t-il une instance dans tous les cas?

Citation:

---

Instances of types that define only static members
do not need to be created. Many compilers will automatically
add a public default constructor if no constructor
is specified. To prevent this, adding an empty private
constructor may be required.

---

http://msdn2.microsoft.com/ms182169(VS.90).aspx.
Ceci

Code:

---

1 2 3 4 5

public static class Class1 { public static void MaMethode() { } }

---

est préférable à

Code:

---

1 2 3 4 5

public class Class1 { public static void MaMethode() { } }

---

A+

Citation:

---

Envoyé par SirJulio

je ne pense qu'il soit ici question de static ou non, mais plutot de methodes d'instances virtual (et peut etre overridée) ou non.

---

Effectivement le benchmark ne fait pas explicitement référence aux méthodes statiques, mais aux appels non-virtuels. Les appels de méthodes statiques sont forcément non-virtuels, d'où ma remarque.

Code:

---

La seule mention de la staticité revient concernant les instanciations de classes, ou le bench met en exergue qu'il est legerement plus long d'instancier une classe qui possede des methodes virtuals qu'une classe n'ayant que des methodes statiques.

---

Surtout qu'une classe qui n'a que des membres statiques n'a aucune raison d'être instanciée... cf. les remarques d'Immobilis sur les recommandations de FXCop

Bonjour

Merci Immobilis pour ta référence.

Je vais marquer résolu le sujet.

Mais ce que je retiens de ça :

C'est que le sujet est très mal maitrisé. j'espère qu'avec ce sujet on vas élever le niveau.

Je vous remercie tous pour votre contribution.

Citation:

---

Envoyé par bartoumi

C'est que le sujet est très mal maitrisé. j'espère qu'avec ce sujet on vas élever le niveau.

---

?
Euh, ... Pas très cool comme remarques... Tu parles de qui?

Du coup, oui, mieux vaut clore la discussion.

A+

Je vise personne au contraire je remercie tout le monde pour sa contribution.

Mais je reconnais que c'est un sujet qui a fait couler beaucoup d'encre(métaphore) et que personne d'entre nous n'as pu apporter une réponse complète ,juste, claire, argumenté et avec des références sérieuses. sauf a la fin avec le lien MSDN que tu apporté.

Moi je la prend comme un AUTO-Critique.

Merci encore une fois a tout le monde

Je trouve que les reponses qui t'ont ete apporte sont toutes tres precices et concretes !

Tu n'as pas su trouver ces reponses, voila tout :mouarf:

Tober

Ce que je met en evidence en rouge c'est pour toi.

Citation:

---

Envoyé par bartoumi

personne d'entre nous n'as pu apporter une réponse complète ,juste, claire, argumenté et avec des références sérieuses.

---

Merci

J'avoue que j'aime bien joue avec les mots aussi. :lol:

Citation:

---

Envoyé par SirJulio

Bref, j'ai l'impression que la plupart du temps, le compilo C# prefere laisser le boulot au runtime, et ne lie statiquement que les methodes statiques (qui par definition sont statiques (sic)). Concernant les impacts en termes de perfs de la resolution des candidats ni la norme, ni les quelques livres parlant de la CLR (Essentials .Net : The CLR; Expert .Net 2.0 IL Assembler) n'en parle, ce qui à mon avis doit etre negligeable (du moins en milieu managé, ou des differences de cet ordre sont noyé dans la masse).

---

Apres plusieurs mois de suspense, on sait enfin pourquoi le compilo C# prefere callvirt a call et on peut enfin clore ce hread : http://blogs.msdn.com/ericgu/archive...-callvirt.aspx

Merci Eric :)