cs_OmbreNoir
Messages postés67Date d'inscriptionsamedi 1 février 2003StatutMembreDernière intervention10 juin 2011
-
22 mai 2007 à 21:15
cs_coq
Messages postés6350Date d'inscriptionsamedi 1 juin 2002StatutMembreDernière intervention 2 août 2014
-
26 mai 2007 à 16:38
J'aimerais savoir si c'est vrai que C# prend beaucoup plus de mémoire vive que les autres languages tel que le c ou le c++.... j'aimerais savoir si il à un moyenne de faire que sa prenne pas trop de mémoire?
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 22 mai 2007 à 21:28
Salut,
C#, comme beaucoup d'autres langages de programmation, est un langage qui est interprété. C'est à dire que le code généré lors de la compilation n'est pas du code machine (comme en C par exemple) mais du MSIL. Ce MSIL devra être traité par le CLR par la suite (il faut bien qu'une fois, on arrive à du code machine...)
Sans rentrer dans les détails, tous les avantages amenés par le framework amènent également (et logiquemnent) certains inconvénients comme la taille utilisée en mémoire (normalement, au moins la taille du framework qui doit être chargé... soit env. 20Mo) et les performances.
Si tu as besoin de faire un code ou la rapidité est la priorité absolue, alors C# n'est probablement pas le langage adéquat à la situation.
Lutinore
Messages postés3246Date d'inscriptionlundi 25 avril 2005StatutMembreDernière intervention27 octobre 201241 22 mai 2007 à 23:23
Le C# possède un compilateur JIT ( just-in-time ) qui compile le code une fois pour toute ce qui permet au C# d'être un language relativement puissant tout de même.
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 23 mai 2007 à 07:52
Oui, mais on arrivera jamais à ce que propose un langage bas niveau (si tu me crois pas, brunews se fera un grand plaisir de te l'expliquer lol )
Plaisanterie à part, pour le JIT, je ne suis pas un pro, mais il me semblait qu'il compilait justement le code à la volée (et pas tout en une fois) ?
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 201017 23 mai 2007 à 09:11
cest exact, mais (si j'ai bien tout compris au JIT) le fait est que puisque ton code est compilé à la volée, il est compilée de la meilleure manière pour ta machine (en bref la compilation à la volée d'un meme programme ne fournira pas forcément le meme résultat sur ma machine ou sur la tienne).
Ca permet de compenser la perte de perf dûe a la compilation a la volée par un code compilé bien plus optimisé que ce que te fournira un code provenant d'une compilation C par exemple (en terme de jeu d'instructions utilisé).
Corrigez moi si je me trompe
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 23 mai 2007 à 10:59
Oui, le code généré par le JiT dépend de la plateforme. Mais il me paraît évident que même avec toutes les optimisations possible, on arrivera pas à des performances égales à des codes de plus bas nouveaux, tel du C.
Il me semble également que le JiT compile juste la partie de code qu'on a besoin, mais le conserve en mémoire pour une exécution ultérieure (si le même code doit être appelé plusieurs fois, il n'a plus besoin d'être recompilé).
Par contre, si on ferme l'application et qu'on la réexecute, je pense que le tout est "réinitialisé", c'est à dire qu'on perd les parties compilées qui ont été sauvées.
A voir
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 201017 23 mai 2007 à 11:31
bidou > je suis d'accord avec absolument tout ca, sauf sur le "on arrivera pas à des performances égales à des codes de plus bas nouveaux, tel du C".
En mémoire on sera toujours a la rammasse par rapport à une application bas niveau.
En terme de performances processeur on sera a priori plus "inégal". En fait si on imagine une application un peu utopique qui tourne longtemps et passe toujours par le meme code, on sera moins performant que du C au départ (compilation a la volée), mais plus performant par la suite (code déjà compilé en tant que code machine), modulo la qualité du code. J'entend par la que si une bonne gestion de la mémoire est effectuée et qu'on évite le maximum de travail au GC, on peut probablement arriver a des performances légèrement supérieures au même code fait en natif. (jai bien dit probablement, j'ai pas fait les tests, d'autant que ca dépend grandement du GC)
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 23 mai 2007 à 12:32
Dans le cas où un programme effectue toujours la même action et qu'il réutilise tout le temps le même code qui est donc déjà 'prêt', peut-être... mais dans la réalité, c'est pas comme ça.
Du coup, j'ai bien peur que C# soit en dessous en terme de performance... Il faudrait effectivement faire des testes pour s'en convaincre
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 201017 23 mai 2007 à 12:40
Le principal "problème de performances" du C# viens des codeurs...beaucoup ont tendance a ne plus optimiser le code "parce que cest le framework qui gère". Combien de fois on voit des listes dont la capacité n'est pas initialisée alors qu'elle pourrait l'être. ou des objets dont le minimum de gestion mémoire n'est pas faite parce que "le GC s'occupe de tout". et j'en passe....
une appli bien codée en C# n'a pas grand chose a envier en terme de temps d'execution à une appli native, ou du moins pas tant que ce que l'on pourrait le croire. (en mémoire et en temps d'initialisation par contre, ca pêche encore, je me demande ce que donnera le framework 3).
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 23 mai 2007 à 13:02
Je ne pense pas que tu as raison... Un programmeur averti n'arrivera pas aux performances d'un code écrit en C (par un programmeur averti aussi). Jette un oeil sur les commentaires de cette source.Ceci dit, je ne prétend pas que C# est 'à chier', je prétends que son point fort n'est pas la performance... et que les langages de plus bas niveaux ont encore un bel avenir devant eux
Lutinore
Messages postés3246Date d'inscriptionlundi 25 avril 2005StatutMembreDernière intervention27 octobre 201241 23 mai 2007 à 13:04
Bidou, j'ai écris "le JIT compile le code une fois pour toute" pas que le code était entièrement compilé en une seule fois. Lorsque que le code atteint une fonction managée elle est compilée en natif puis dechargée, très rapidement on se retrouve plus qu'avec du code natif. c'est pour ça que je dis qu'il est relativement puissant.. du moins par rapport a ce que pourrait laisse croire le terme "language interprété".
La compilation JIT est valable uniquement pendantl'exécution du programme, le fichier n'est pas modifié, si on ferme l'application on perd le code natif. Pour compiler définitivement en natif faut passer par le compilateur NGen du framework.
C'est vrai que le JIT optimise le code pour une plateforme donnée, mais je pense pas que ça joue tant que ça sur les perfs même si il y a un adage qui dit qu'un code passe 80% de son temps dans 20% de son code, mais face a un code C bien écris et bien optimisé le C# ne peut plus rivaliser, mais il a d'autres avantages que le C/C++ n'a pas, gestion de la mémoire, gestion de la sécurite etc..
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 23 mai 2007 à 14:11
lutinore> pour le JiT, j'avais lu trop rapidement ton poste
Je viens de me taper les 8 pages de forum (le lien que tu as donné), discussion intéressante mais... mon point de vue reste le même!
C# et ce qui gravite autour amènent leurs lots d'avantages mais également certains inconvénients. Le tout est de les connaître.
leprov
Messages postés1160Date d'inscriptionvendredi 23 juillet 2004StatutMembreDernière intervention21 octobre 201017 23 mai 2007 à 15:17
attention ne me faites pas dire ce que j'ai pas dit !!
je suis parfaitement conscient que C# a son lot de désavantages (sinon quel interet de continuer a programmer en C/C++ sous windows?) !
je dis simplement que (et ca sera peut etre plus clair ^^) :
-Le code C# est en moyenne moins performant que du code natif
-Grace au JIT, le code C# reste largement performant
-la présence du GC pondère le gain de performances amenées par le JIT (en bref, sans GC, le C# amènerais des perfs similaires voire supérieures dans du code déjà passé au JIT)
-les mauvaises perfs dans des programmes C# sont plus souvent dues a de la mauvaise programmation plus qu'au langage lui meme (bcp ne cherchent pas a optimiser et cest pour ca qu'ils utilisent le C#. Je regarde simplement certains collègues de boulot qui refusent d'utiliser un StringBuilder, d'initiliser une capacité, ou de gérer correctement les destructions d'objets sous pretexte qu'on est en langage haut niveau sur des machines puissantes....alors on fait moins de lignes de codes...de moins bonnes perfs parce qu'on est moins propre, mais moins de lignes de code).
après je ne suis pas la a défendre aveuglément le langage et a le bénir corps et ame avec le plus de mauvaise foi possible :D
cs_coq
Messages postés6350Date d'inscriptionsamedi 1 juin 2002StatutMembreDernière intervention 2 août 2014101 26 mai 2007 à 16:38
Ceux qui refusent d'utiliser le StringBuilder dans une boucle après avoir été avertis devraient être licensiés pour faute... (oui, ça m'énerve).
Pour le problème de lenteur du démarrage, vous devriez regarder du côté de ngen.