Envoyé par
fofo
Envoyé par
lechenejb
.Net bouffe pas de mémoire, au contraire, il implémente le Garbage Collector qui évite les fuites mémoires non gérées !
Le garbage collector y'en a dans Windows est donc les logiciels dévellopés à la old-school (C,C++) en profite également...
N'importe quoi ! quand tu fais malloc(22); en C ta mémoire se sera jamais libérée tant que ton programme tourne.
Envoyé par
fofo
.Net implémente un garbage collector car comme java c'est un langage compilé en "micro-code" (enfin pas de l'assembleur) donc le garbage collector de windows ne peut pas s'appliquer...
Windows n'a pas de garbage collector ....
Envoyé par
fofo
".Net ne boouffe pas de mémoire !!!" : Install les pilotes "Ati .net" reboote fait Ctrl+Alt+Suppr et compte combien de mémoire te prennent les processus CLI.exe :whistle:
.Net bouffe forcément plein de mémoire, parceque tu dévellopes un simple "Hello World" ou une suite de bureautique complète, tu charges tout le framework .Net à chaque lancement de ton applis :whistle:
Une instance de VM .NET prends 10Mo ce qui est peut quand on voit tout ce qu'on peut faire avec. Par exemple une instance de VS.NET c'est 11Mo et c'est autrement plus compliqué que ton "helle world"
Envoyé par
fofo
Oui mais en ce moment je dévellope en Java sous Linux :whistle: donc il risque d'avoir comme un soucis :wink:
il y a mono et #developp
Envoyé par
fofo
ouais java aussi... néanmoins il prend plein de mémoire.
Quand tu lances une JVM tu lui alloue un espace mémoire initiale 64MO (je crois), en java le garbage-collector n'est appelé que lorsque cet espace mémoire est plein pour réallouer la mémoire dont tu ne te sers plus
Avec la JVM c'est configurable, tu peux démarrer avec 16Mo si tu veux. Tu donne une taille mini (-XMS) et un max (-XMX) et le comportement du GC est configurable aussi (-NEWGC et CONCSwep en SMP). La JVM va libérer la mémoire a la première occasion et pas quand c'est plein, c'est généralement au moment ou tu as besoin de plein de mémoire que t'as pas envie de te faire pourrir tes perfs par de la dés-allocation (assez couteuse en %cpu). Pour info sur nos serveurs on est passé de 100 clients concurent a plus de 400 en tunant la JVM.
Perso j'aime beaucoup coder en Java et en c#. Je trouve que Java permet de coder plus vite mais est plus limité. C# est vraiment très bon aussi, même si c'est beaucoup repompé sur Java, qui lui même avait repomper sur d'autres (comme Smalltalk), on s'en fout, l'intéressant est la finalité. C# permet plus facilement de faire du code bourrin grace au code unmanaged et a la facilité de dev en COM/DCOM. Le JNI de Java est plus aléatoire et moins bien supporté.
Je travaille actuellement dans un environement "Serveur Java" et "Client graphique en C#" et je trouve que c'est le meilleur des deux mondes.