Sans parler que c'est aussi s'imposer une limite concernant les performances.... Ce qui peut être un problème pour un langage qui se veut "avec des performances proches du C".
En réalité c'est un problème très subtil, un cas classique où un programme ou la mémoire est gérée de façon manuelle va se comporter plus mal qu'un programme dont la mémoire est gérée automatiquement, est celui d'un programme avec des allocations de longue durée qui va fractionner sa mémoire. Le fractionnement de la mémoire a un impact critique sur la performance lorsqu'il empêche la localisation des données en mémoire, c'est à dire lorsqu'à cause du fractionnement, les données allouées simultanément pour un calcul vont se retrouver dans des pages de cache différentes. Dans un langage où la mémoire est gérée automatiquement, le ramasse-miette peut déplacer les données en mémoire et garantir une bonne localisation tandis que dans un langage comme C, c'est impossible de garantir cette localisation sans utiliser un système spécialisé.
[^] # Re: Destructeurs
Posté par Michaël (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6.
En réalité c'est un problème très subtil, un cas classique où un programme ou la mémoire est gérée de façon manuelle va se comporter plus mal qu'un programme dont la mémoire est gérée automatiquement, est celui d'un programme avec des allocations de longue durée qui va fractionner sa mémoire. Le fractionnement de la mémoire a un impact critique sur la performance lorsqu'il empêche la localisation des données en mémoire, c'est à dire lorsqu'à cause du fractionnement, les données allouées simultanément pour un calcul vont se retrouver dans des pages de cache différentes. Dans un langage où la mémoire est gérée automatiquement, le ramasse-miette peut déplacer les données en mémoire et garantir une bonne localisation tandis que dans un langage comme C, c'est impossible de garantir cette localisation sans utiliser un système spécialisé.