J'ai fait du dev en Java pour des cibles embarquées avec quelques centaines de kilo-octets de RAM. Avec un garbage collector.
Et ben on était bien content, non pas parce que c'est rapide, mais surtout parce que ça permettait de déplacer les objets en mémoire de façon transparente pour le code. On pouvait donc défragmenter la mémoire et ainsi libérer de grands espaces contigus pour pouvoir allouer de gros objets.
De la même façon, les stacks pour les threads pouvaient être allouées dynamiquement par tout petits blocs (quelques dizaines ou centaines d'octets à la fois) en fonction des besoins de chaque thread.
La consommation mémoire était donc bien inférieure à un code essayant de faire la même chose en C. Et ça justifiait largement de dédier un peu de puissance CPU au garbage collector.
# L'abstraction c'est bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 10.
J'ai fait du dev en Java pour des cibles embarquées avec quelques centaines de kilo-octets de RAM. Avec un garbage collector.
Et ben on était bien content, non pas parce que c'est rapide, mais surtout parce que ça permettait de déplacer les objets en mémoire de façon transparente pour le code. On pouvait donc défragmenter la mémoire et ainsi libérer de grands espaces contigus pour pouvoir allouer de gros objets.
De la même façon, les stacks pour les threads pouvaient être allouées dynamiquement par tout petits blocs (quelques dizaines ou centaines d'octets à la fois) en fonction des besoins de chaque thread.
La consommation mémoire était donc bien inférieure à un code essayant de faire la même chose en C. Et ça justifiait largement de dédier un peu de puissance CPU au garbage collector.