D'une part un compteur de référence est une forme de garbage collector
On peut jouer avec les mots, mais ce n'est pas un garbage collector classique mark & sweep ou generationel et ça n'en a pas les propriétés. Ça n'a ni les problemes de lifetime associés au GC GC classiques, ni les problemes de surconsommation memoires ( meme si ca en a d'autres ) . Ce qui le rend par ailleurs beaucoup plus facile a interfacer avec du C/C++ que du Java... entre autres...
Inexact. En fonction de la façon dont ton application alloue et désalloue la mémoire, un GC peut s'avérer plus performant qu'une gestion manuelle. En particulier si tu as des structures profondes (arbres ou listes) que tu modifies peu au cours de leur vie (i.e tu les alloues, tu les utilises sans les modifier, puis tu les désalloues). Dans ce cas, un bon GC pourra tout désallouer d'un coup alors qu'une gestion manuelle t'obligera à désallouer chaque nœud de ta structure.
Pour reprendre ton pattern.
Non. Une gestion manuelle bien fait sera toujours plus performante et plus facile à profiler. Un GC peut savouer un poil plus performant qu'une gestion manuelle naive dans certains cas précis. Le cas que tu cites se résoud avec une simple Memory Pool local au life time de ton graphe.
Faux. Il existe des GC temps réel (donc qui garantissent une latence max). Bien sur, on n'a rien sans rien et ces GC sont généralement encore plus gourmands en mémoire que les autres.
Non. Ça c'est ce au'on nous annonce depuis 10 ans environ. Fait est qu'en pratique, même Android malgrés les sommes colossales investi par Google dans Dalvik, continue d'avoir des problèmes de latence associés á son GC.
Note que de toutes façons ceux qui développent des systèmes vraiment critiques en termes de performances (jeux, par ex.) évitent les allocations dans la partie critique (aussi bien avec un GC, qu'avec malloc) car ni l'un ni l'autre n'ont de performances garanties.
Non. Ça c'est la théorie. En pratique tu ne peux pas éviter d'avoir des allocations même dans la partie critique. Ce que en C/C++ tu compenseras par un pool allocator, un stack allocator ou par l'utilisation de jemalloc, tcmalloc ou le tbbmalloc si ton problème vient d'un haut niveau de concurrence. Toutes ces strategies sont communément deployé dans des apps que vous utilisez tous les jours ( jeux video, database, server web, etc, etc )
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 4. Dernière modification le 10 mai 2016 à 09:16.
On peut jouer avec les mots, mais ce n'est pas un garbage collector classique mark & sweep ou generationel et ça n'en a pas les propriétés. Ça n'a ni les problemes de lifetime associés au GC GC classiques, ni les problemes de surconsommation memoires ( meme si ca en a d'autres ) . Ce qui le rend par ailleurs beaucoup plus facile a interfacer avec du C/C++ que du Java... entre autres...
C'est plutot bien detaillé ici par ailleurs ( http://effbot.org/pyfaq/how-does-python-manage-memory.htm )
Pour reprendre ton pattern.
Non. Une gestion manuelle bien fait sera toujours plus performante et plus facile à profiler. Un GC peut savouer un poil plus performant qu'une gestion manuelle naive dans certains cas précis. Le cas que tu cites se résoud avec une simple Memory Pool local au life time de ton graphe.
Non. Ça c'est ce au'on nous annonce depuis 10 ans environ. Fait est qu'en pratique, même Android malgrés les sommes colossales investi par Google dans Dalvik, continue d'avoir des problèmes de latence associés á son GC.
Non. Ça c'est la théorie. En pratique tu ne peux pas éviter d'avoir des allocations même dans la partie critique. Ce que en C/C++ tu compenseras par un pool allocator, un stack allocator ou par l'utilisation de jemalloc, tcmalloc ou le tbbmalloc si ton problème vient d'un haut niveau de concurrence. Toutes ces strategies sont communément deployé dans des apps que vous utilisez tous les jours ( jeux video, database, server web, etc, etc )