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.
C'est le genre d'argumentation qui a le don de m'énerver. Un bon GC est meilleure qu'un mauvais programmeur : ho la bonne surprise. Je vais te la faire à l'envers : un mauvais GC est pire qu'un bon programmeur ! Et on a bien fait avancer le bouzin.
Dans le cas très particulier que tu cites «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)», déjà ce n'est pas la désallocation qui prendra énormément de temps si ce sont des structures à durée de vie longue, donc chipoter sur le temps de désallocation, je ne comprends pas bien.
Ensuite, rien n'empêche d'utiliser un allocateur spécifique pour ce cas là, genre j'alloue un gros tas de mémoire et je déplace un pointeur pour chaque nœud et quand je veux tout désallouer d'un coup, ben je fais free sur mon gros tas de mémoire. Un programmeur correct sait faire ça assez vite et ça va aussi bien que ton super-GC (voire mieux parce que tous les nœuds seront alloués dans une zone contiguë). Ce genre d'allocateur existe dans beaucoup de bibliothèques.
[^] # Re: Destructeurs
Posté par rewind (Mastodon) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 7.
C'est le genre d'argumentation qui a le don de m'énerver. Un bon GC est meilleure qu'un mauvais programmeur : ho la bonne surprise. Je vais te la faire à l'envers : un mauvais GC est pire qu'un bon programmeur ! Et on a bien fait avancer le bouzin.
Dans le cas très particulier que tu cites «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)», déjà ce n'est pas la désallocation qui prendra énormément de temps si ce sont des structures à durée de vie longue, donc chipoter sur le temps de désallocation, je ne comprends pas bien.
Ensuite, rien n'empêche d'utiliser un allocateur spécifique pour ce cas là, genre j'alloue un gros tas de mémoire et je déplace un pointeur pour chaque nœud et quand je veux tout désallouer d'un coup, ben je fais
freesur mon gros tas de mémoire. Un programmeur correct sait faire ça assez vite et ça va aussi bien que ton super-GC (voire mieux parce que tous les nœuds seront alloués dans une zone contiguë). Ce genre d'allocateur existe dans beaucoup de bibliothèques.