Le ref count a le problème immense de rajouter une opération dés que tu fais une affectation, ce qui a offre une grosse pénalité. Ce n'est pas pour rien que aucune VM n'utilise de ref count(sauf perl). Dans le cas avec ref count, tu fais des opération en plus à chaque affectation et tu désalloues la mémoire lors de la perte d'une référence (compteur à zéro). Dans les autres cas, il n'y aucune opération en plus dans ses 2 cas. Dans beaucoup d'allocateurs mémoire rapide, le "free" doit se faire sur un grand nombre d'objet pour gagner beaucoup de temps (allocateur d'apache par exemple).
Dans les gc modernes, ils sont souvent générationnels avec d'autres zones mémoire et d'autres algo en fonction de l'age des données. Dans ocaml, il y a un GC par copie sur une petite zone (250ko ?, cela permet aussi de lutter contre la fragmentation), puis un mark&sweep (de mémoire).
[^] # Re: templates variadiques
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 4.
Le ref count a le problème immense de rajouter une opération dés que tu fais une affectation, ce qui a offre une grosse pénalité. Ce n'est pas pour rien que aucune VM n'utilise de ref count(sauf perl). Dans le cas avec ref count, tu fais des opération en plus à chaque affectation et tu désalloues la mémoire lors de la perte d'une référence (compteur à zéro). Dans les autres cas, il n'y aucune opération en plus dans ses 2 cas. Dans beaucoup d'allocateurs mémoire rapide, le "free" doit se faire sur un grand nombre d'objet pour gagner beaucoup de temps (allocateur d'apache par exemple).
Dans les gc modernes, ils sont souvent générationnels avec d'autres zones mémoire et d'autres algo en fonction de l'age des données. Dans ocaml, il y a un GC par copie sur une petite zone (250ko ?, cela permet aussi de lutter contre la fragmentation), puis un mark&sweep (de mémoire).
"La première sécurité est la liberté"