Avantages et inconvénients de l’utilisation de SetProcessWorkingSetSize

J’ai un problème avec la gestion de la mémoire dans mon application. La mémoire de l’application grandit rapidement pendant l’exécution. J’utilise des ensembles de données en mode déconnecté. Pour résoudre ce problème, je SetProcessWorkingSetSize fréquemment le DS et utilise également SetProcessWorkingSetSize pour gérer l’utilisation de la mémoire. Cela fonctionne bien dans mon ordinateur de développement. Quels sont les avantages et les inconvénients de l’utilisation de SetProcessWorkingSetSize ?

    SetProcessWorkingSetSize () contrôle la quantité de RAM utilisée par votre processus, sans affecter la taille de la mémoire virtuelle de votre processus. Windows est déjà assez performant pour contrôler cela de manière dynamic, en échangeant des pages de mémoire à la demande lorsqu’un autre processus a besoin de RAM. En procédant ainsi manuellement, vous ralentissez beaucoup votre programme, ce qui entraîne de nombreuses erreurs de page lorsque Windows est obligé de réintégrer les pages de mémoire. SetProcessWorkingSetSize est généralement utilisé pour augmenter la quantité de RAM allouée à un processus. Ou pour forcer un ajustement lorsque l’application sait qu’elle va restr inactive pendant longtemps. Aussi fait automatiquement par les anciennes versions de Windows lorsque vous réduisez la fenêtre principale de l’application.

    Inutile de localiser ce fichier, vous pouvez utiliser les propriétés Process.GetCurrentProcess.Min / MaxWorkingSet.

    Le seul cas d’utilisation intéressant que j’ai vu pour cet appel est que lorsque vous SAVEZ que votre processus va absorber une grande partie de la mémoire vive du système et que vous souhaitez le réserver pour la durée. Vous l’utilisez pour dire à l’OS “Oui, je vais manger beaucoup de la RAM du système pendant toute ma course et ne me gêne pas”.

    Dans cette situation, laisser le comportement par défaut du système d’exploitation est mauvais. Le système d’exploitation alloue un nombre de Mo de RAM par défaut à chaque processus, essentiellement son espace de travail. Ses heuristiques de gestion des ressources ne sont pas des oracles, donc si elles détectent un processus mangeant plus que sa part de ressources système (comme la RAM), elles essaieront de récupérer autant de ressources que possible. Pour VOTRE processus, cela signifie que le système d’exploitation gaspillera beaucoup de ressources CPU (et donc nuisera à vos performances) en paginant la mémoire à l’intérieur et à l’extérieur de votre espace d’adressage lorsque cela n’est pas nécessaire.

    Nous avons découvert que pour une application graphique écrite en Delphi pour Win32 / Win64 ou écrite de manière similaire à des bibliothèques volumineuses et lourdes au-dessus de l’API Win32 (GDI, etc.), il est utile d’appeler SetProcessWorkingSetSize une fois.

    Nous l’appelons avec les parameters -1, -1, dans une fraction de seconde après que l’application s’est complètement ouverte et a montré la fenêtre principale à l’utilisateur. Dans ce cas, SetProcessWorkingSetSize (… -1, -1) libère un grand nombre de codes de démarrage qui ne semblent plus nécessaires. La mémoire restaure rapidement à environ 1/3 de ce qu’elle aurait été sans SetProcessWorkingSetSize (… -1, -1), mais ne grossissait pas davantage. Nous avons donc effectivement économisé les 2/3 de la mémoire du code de démarrage (chargement et parsing des fichiers de configuration, initialisation de l’interface graphique, etc.) qui n’auraient peut-être jamais été nécessaires.

    Si vous avez une application graphique, vous pouvez tester sur votre propre application de la même manière – il suffit de l’appeler une fois et de voir combien de mémoire ont été définitivement libérées.

    Même pour une application serveur (service) sans interface graphique – je pense que l’appel de SetProcessWorkingSetSize une fois que le serveur est complètement chargé et initialisé aurait pu être utile.