Chaque fois que vous avez une application dont le chemin critique est gourmand en performances, vous devez vous préoccuper de la façon dont vous traitez la mémoire. La plupart des applications côté client de l'utilisateur final n'entrent pas dans cette catégorie car elles sont principalement pilotées par les événements et la plupart des événements proviennent d'interactions avec l'utilisateur, et cela n'a pas autant (voire pas du tout) de contraintes de performances.
Cependant, beaucoup de logiciels back-end devraient se concentrer sur la façon dont la mémoire est gérée car beaucoup de ces logiciels peuvent évoluer pour gérer un nombre plus élevé de clients, un plus grand nombre de transactions, plus de sources de données .... Une fois que vous démarrez repoussant les limites, vous pouvez commencer à analyser la façon dont vos utilisateurs de logiciels mémorisent et écrire des schémas d'allocation personnalisés adaptés à votre logiciel plutôt que de compter sur un allocateur de mémoire complètement générique qui a été écrit pour gérer tout cas d'utilisation imaginable.
Pour vous donner quelques exemples ... dans ma première entreprise, j'ai travaillé sur un progiciel Historian, un logiciel responsable de la collecte / stockage / archivage des données de contrôle de processus (pensez à une usine, une centrale nucléaire ou une raffinerie de pétrole avec 10 millions de capteurs, nous stockons ces données). Chaque fois que nous analysions un goulot d'étranglement des performances qui empêchait l'Historian de traiter davantage de données, la plupart du temps, le problème était dans la façon dont la mémoire était gérée. Nous avons fait de grands efforts pour nous assurer que malloc / free n'était pas appelé, sauf si c'était absolument nécessaire.
Dans mon travail actuel, je travaille sur l'enregistreur numérique de vidéosurveillance et le package d'analyse. À 30 ips, chaque canal reçoit une trame vidéo toutes les 33 millisecondes. Sur le matériel que nous vendons, nous pouvons facilement enregistrer 100 canaux de vidéo. C'est donc un autre cas pour s'assurer que dans le chemin critique (appel réseau => composants de capture => logiciel de gestion de l'enregistreur => composants de stockage => disque) il n'y a pas d'allocations de mémoire dynamique. Nous avons un allocateur de trames personnalisé, qui contient des compartiments de taille fixe de tampons et utilise LIFO pour réutiliser les tampons précédemment alloués. Si vous avez besoin de 600 Ko de stockage, vous pourriez vous retrouver avec un tampon de 1024 Ko, ce qui gaspille de l'espace, mais parce qu'il est spécialement conçu pour notre utilisation où chaque allocation est de très courte durée, cela fonctionne très bien car le tampon est utilisé,
Dans le type d'applications que j'ai décrit (déplacer de nombreuses données de A vers B et gérer un grand nombre de demandes des clients), aller vers le tas et revenir est une source majeure de goulots d'étranglement des performances du processeur. Garder la fragmentation des segments au minimum est un avantage secondaire, mais pour autant que je sache, la plupart des systèmes d'exploitation modernes implémentent déjà des segments à faible fragmentation (au moins, je sais que Windows le fait, et j'espère que d'autres le feront aussi). Personnellement, depuis plus de 12 ans travaillant dans ces types d'environnements, j'ai vu des problèmes d'utilisation du processeur liés au tas assez fréquemment, alors que je n'ai jamais vu un système qui souffrait réellement d'un tas fragmenté.