plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?
Un GC ne se contente pas de libérer la mémoire, il peut aussi éviter sa fragmentation.
typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents
Un bon GC peut être désactivé/réactivé. Tu peux forcer un GC quand ça t'arrange. Et dans le cas des GC générationnels (dont sont dotés les langages que j'utilise) tu peux même spécifier quelle génération collecter. Pour finir un bon GC est souvent configurable.
Jette un oeil du côté des SBCL ou CCL. Je n'ai jamais eu de longue pause pour le GC avec ceux-ci. J'ai plutôt l'impression que ce préjugés date un peu. Ou alors ce sont les GC de Perl/Python/Ruby (qui ne sont pas très évolués) qui ont engendré cette mauvaise image.
[^] # Re: Interrogations...
Posté par Thomas . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 1.
Un GC ne se contente pas de libérer la mémoire, il peut aussi éviter sa fragmentation.
typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents
Un bon GC peut être désactivé/réactivé. Tu peux forcer un GC quand ça t'arrange. Et dans le cas des GC générationnels (dont sont dotés les langages que j'utilise) tu peux même spécifier quelle génération collecter. Pour finir un bon GC est souvent configurable.
Jette un oeil du côté des SBCL ou CCL. Je n'ai jamais eu de longue pause pour le GC avec ceux-ci. J'ai plutôt l'impression que ce préjugés date un peu. Ou alors ce sont les GC de Perl/Python/Ruby (qui ne sont pas très évolués) qui ont engendré cette mauvaise image.