Voici quelque chose que je ne peux pas laisser passer a nouveau :-) > Cela me fait bondir... et me rappelle l'introduction de Roberto di Cosmo > pour son livre sur la face cachée de Microsoft. Il expliquait qu'il se > trouvait un jour dans un train en face d'une personne équipée d'un > ordinateur portable, et cette personne montrait ostensiblement sa fierté > après avoir passer quelques heures à "nettoyer" sa machine grâce à > "l'excellent défragmentateur de Windows". Roberto di Cosmo expliquait que > si la machine avait correctement fait son ménage au fur et à mesure de son > travail, tout comme une bonne secrétaire classe briévement et régulièrement > les dossiers qui arrivent, il n'aurait jamais eu à faire le grand nettoyage > de printemps, tout comme une mauvaise secrétaire laisserait le bordel > s'accumuler avant de devoir passer plusieurs jours à tout ranger. > Si je voulais provoquer, je pourrais dire que le Garbage Collector est fait > pour les développeurs bordéliques et indisciplinés, alors qu'une bonne > hygiène de développement impose de "nettoyer" régulièrement sa mémoire. Il > s'agit d'hygiène de développement. Et Java ne permet pas de nettoyer > régulièrement sa mémoire: le développeur n'a presque aucune maitrise sur le > nettoyage (il peut tout au plus l'influencer avec le finalize, mais pas > plus).
Mettons les choses au point : il est moins couteux d'utiliser un garbage collecteur que les systemes a la malloc. En effet, l'allocation d'un objet avec un GC se fait presque toujours en temps constant (sauf quand cette allocation deborde, et qu'il faut effectivement "garbeger"), alors qu'un malloc suivit d'un free est *tres* couteux ! En effet, il y a des listes chainees d'"espace utilisable" dessous. Quand on fait un malloc, on parcour la liste a la recherche d'un emplacement suffisant, tandis qu'un free se charge de remettre cet emplacement dans la liste. > D'autre part, cela n'empêche pas les fuites mémoires (eh oui!): pour un > code Java "industriel", il vaut donc mieux jeter un oeil avisé sur la > gestion de la mémoire dans le développement de l'application. Je suis d'accord... L'utilisation d'un GC, meme etant plus rapide, peut vite devenir penalisante. De plus, l'utilisation du gc permet de decharder le programmeur de cette tare qu'est la gestion memoire, pour ne s'occuper vraiment de la gestion de flux de son application. > Enfin, là où C++ permet d'allouer (statiquement) sur la pile/stack (et > dynamiquement sur le tas/heap), Java n'alloue que dynamiquement sur le > tas/heap. Quand on sait qu'il y a un rapport de 1 à 10 entre ces deux types > d'allocation (statique/dynamique), on obtient une autre raison pour > laquelle Java restera toujours plus lent que C++. Humm... D'apres mon experience, je n'ai pas vu beaucoup de personne utiliser alloca au lieu d'un bon malloc ou d'un new. De plus, l'utilisation d'un GC libere le programmeur de la gestion des pointeurs, ce qui est vraiment loin d'etre negligeable... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._ Bergel Alexandre http://www.iam.unibe.ch/~bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^ Linux-Azur : http://www.linux-azur.org Désinscriptions: http://www.linux-azur.org/liste.php3 **** Pas de message au format HTML, SVP ****
