Python n'utilise pas de garbage collector mais un compteur de référence
D'une part un compteur de référence est une forme de garbage collector (*), d'autre part Python a un « vrai » GC pour gérer les cycles, qui peut être contrôlé avec le module gc :
importgc# Empêcher le GC de se déclencher automatiquement :gc.disable()# Déclencher manuellement un cycle de collecte :gc.collect()# Ré-activer le GC :gc.enable()
(*) Un garbage collector est un mécanisme qui libère automatiquement la mémoire quand elle n'est plus utilisée, selon cette définition un compteur de références est un garbage collector.
un GC a un coût, en terme de performance,
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.
en terme de ressources ( 2x à 8x la quantité de mémoire ),
Vrai, du moins tant que ton appli n'a pas de fuites mémoire. C'est pour cette raison que les langages à GC ne perceront jamais dans l'embarqué (je parle ici du vrai embarqué, celui où les ressources sont limitées, pas des ordiphones qui sont plus puissants que le PC que j'avais il y a cinq ans).
en terme de déterminisme, en terme de latence.
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. 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.
Les GC ne sont pas la panacée mais ils ont leur utilité, en particulier :
lorsque réduire le temps de développement est plus important que d'économiser quelques cycles CPU ou quelques MB de RAM (un développeur coûte beaucoup plus cher que d'acheter une machine plus puissante ou de répartir la charge entre plusieurs machines),
lorsque de toutes façons le système est tellement critique qu'aucune allocation n'est faite dans la boucle principale. Dans ce cas rien n'empêche d'utiliser un GC pour les allocations qui, par définition, auront lieu en dehors de la partie critique.
[^] # Re: Destructeurs
Posté par jeberger (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 10.
D'une part un compteur de référence est une forme de garbage collector (*), d'autre part Python a un « vrai » GC pour gérer les cycles, qui peut être contrôlé avec le module
gc:(*) Un garbage collector est un mécanisme qui libère automatiquement la mémoire quand elle n'est plus utilisée, selon cette définition un compteur de références est un garbage collector.
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.
Vrai, du moins tant que ton appli n'a pas de fuites mémoire. C'est pour cette raison que les langages à GC ne perceront jamais dans l'embarqué (je parle ici du vrai embarqué, celui où les ressources sont limitées, pas des ordiphones qui sont plus puissants que le PC que j'avais il y a cinq ans).
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. 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.Les GC ne sont pas la panacée mais ils ont leur utilité, en particulier :
lorsque réduire le temps de développement est plus important que d'économiser quelques cycles CPU ou quelques MB de RAM (un développeur coûte beaucoup plus cher que d'acheter une machine plus puissante ou de répartir la charge entre plusieurs machines),
lorsque de toutes façons le système est tellement critique qu'aucune allocation n'est faite dans la boucle principale. Dans ce cas rien n'empêche d'utiliser un GC pour les allocations qui, par définition, auront lieu en dehors de la partie critique.