Pourquoi concevoir un gestionnaire de mémoire personnalisé?

Les performances ne sont pas la seule raison de développer un allocateur personnalisé. D'autres raisons peuvent inclure:

1. Meilleures capacités de débogage .
   Ne serait-il pas agréable d'avoir un gestionnaire de mémoire qui peut aider à localiser certaines erreurs de programmation courantes comme l'utilisation de la mémoire non initialisée, l'accès à la mémoire en dehors du bloc alloué, double libre, utilisation après libre? Cependant, un bon gestionnaire de mémoire de système d'exploitation peut déjà offrir toutes ces fonctionnalités prêtes à l'emploi.
2. Imposition de quotas d'utilisation de la mémoire .
   Dans les projets plus importants, vous pourriez vous inquiéter des problèmes de mémoire, surtout si certains modules tiers sont utilisés. Mieux vaut ne pas laisser un module non fiable affamer tous les autres modules.
3. Allocation garantie .
   Parfois, vous voulez vous assurer qu'une certaine fonction critique ne peut jamais échouer. Préallouer une grande partie de la mémoire et fournir un allocateur personnalisé peut être l'une des étapes requises.
4. Nettoyage forcé de la mémoire après des plug-ins non approuvés.
   Protéger votre application contre les mêmes scénarios malsains qu'avec les porcs de mémoire.
5. Un système autonome peut ne pas avoir du tout de gestionnaire de mémoire. : -)

Il est rarement nécessaire de concevoir un gestionnaire de mémoire personnalisé. Il y en a tellement que la plupart des gens peuvent en trouver un à utiliser sur le support. Il y a quelques années, j'avais un système C ++ qui comprenait un interpréteur. Lors des premiers tests, ce n'était pas aussi rapide que nous l'avions espéré. Le profilage a montré que le problème était l'allocation de mémoire et il s'est manifesté dans la classe de chaîne. Nous avons téléchargé environ deux douzaines de gestionnaires de mémoire sur Internet et avons essayé chacun d'eux à tour de rôle. Nous avons pu obtenir une amélioration massive de la vitesse. Le gestionnaire de mémoire, nous avons fini par utiliser des blocs toujours alloués dans des tailles qui étaient des puissances de 2 et maintenait des pools séparés pour chaque taille de bloc.

Nous avons trouvé plus de gestionnaires de mémoire que nous ne pourrions en tester.

Généralement, la plus grande motivation pour créer un allocateur personnalisé n'a rien à voir avec les performances. Au lieu de cela, les programmes qui doivent fonctionner sur une grande variété de systèmes se retrouvent dans des bibliothèques incohérentes et / ou incomplètes. La bibliothèque std en particulier. De plus, les limitations matérielles des systèmes embarqués exigent souvent que les applications fassent très attention à l'utilisation et à la gestion de la mémoire. Ces programmes exécutent tout, de la climatisation de votre voiture au pilote automatique des avions. Il existe également des systèmes qui n'ont pas de pile nécessitant une gestion minutieuse du tas. Ces exemples ne sont que la pointe de l'iceberg. Ajoutez à cela un allocateur de base, comme l'une des nombreuses conceptions basées sur la pile, et vous obtenez une solution très simple à écrire, facile à entretenir et hautement performante. Une autre raison d'écrire votre propre allocateur est tout simplement de manquer de mémoire. Celui-ci apparaît généralement lorsqu'il y a beaucoup de mémoire "libre", mais pas de blocs assez grands pour remplir une requête. Cela signifie que la mémoire est devenue fragmentée au sein de l'allocateur. Google "allocateur de mémoire facebook" pour un exemple.

Le seul thème commun à tous ces programmes est le besoin d'un gestionnaire de mémoire spécifique à une solution. C'est la raison pour laquelle il y a tant de gestionnaires disponibles gratuitement. S'il n'y a pas de besoin spécifique, il n'y a aucune bonne raison d'utiliser autre chose que malloc / new. Ou, mieux encore, établir une stratégie qui nécessite l'utilisation de pointeurs intelligents qui gèrent les allocations de mémoire en arrière-plan. Le profilage de la mémoire et la statistique se font facilement avec un outil externe et constituent généralement la première étape que les programmeurs prennent sur le chemin d'un gestionnaire de mémoire spécifique à une solution. Vous ne devriez jamais commencer avec un "gestionnaire de mémoire générique" et demander plus tard "pourquoi j'utilise ceci".

Enfin, votre utilisation du terme «gestionnaire de stockage» fait référence à une classe beaucoup plus large d'outils qui gèrent généralement les données de la mémoire à court terme au stockage et à l'archivage à long terme. Ces outils sont beaucoup plus rares, peuvent être très complexes et, encore une fois, sont un outil spécifique à une solution qui doit être utilisé pour des besoins spécifiques tels qu'une base de données.

Les performances sont généralement la dernière raison pour inclure un gestionnaire de mémoire dans un programme, cela étant dit, si un gestionnaire de mémoire ne peut pas surpasser le système d'au moins un facteur de 2, alors quelque chose ne va vraiment pas. Soit le programme a trouvé un cas dégénéré pour le gestionnaire, soit le gestionnaire lui-même a un problème qui doit être résolu.