Ughh. Le gestionnaire de tâches est un outil assez pauvre pour mesurer les performances.
Par exemple, lorsque j'évalue la performance d'une équipe sportive, est-ce que je regarde les statistiques d'un seul match ou de plusieurs ?
En outre, le cerveau humain accorde plus d'importance, et donc de poids, aux points de données récents qu'à des points de données peut-être plus significatifs mais éloignés.
Le mythe de la mémoire libre
D'après ce que j'ai compris, le système devrait toujours conserver quelques pages "libres" (c'est-à-dire mises à zéro) afin de pouvoir les >mapper rapidement lorsqu'un processus le demande (afin que les pages puissent être libérées par une autre unité centrale pendant que le >processus demandeur peut continuer).
La mise à zéro des pages de mémoire est un processus assez trivial sur les machines d'aujourd'hui. L'accès au disque, même avec des disques SSD haut de gamme, domine la liste des facteurs de performance lents. Il y a une raison pour laquelle la mémoire libre et l'accès au disque sont corrélés en termes de performances, puisque pour une application, ils sont une seule et même chose : un stockage secondaire. Bien qu'une mémoire insuffisante puisse amener un système d'exploitation à utiliser le disque, d'après mes observations des graphiques de perfmon, l'accès au disque et la latence du réseau (Ughh, je déteste notre fournisseur d'accès) dominent les problèmes de performance actuels.
Il est également impossible de lire l'impact d'avoir de la mémoire libre (pages mises à zéro) sur votre machine. Nous n'avons aucune idée du pic de commits, du pic de # de fautes de page, du # de pages, etc. Je vous mets en garde contre les conclusions hâtives sur ce qui est littéralement un instantané .
Mes suggestions
Prenez de nombreux points de données.
Si vous avez un accès administrateur local à votre machine, lancez perfmon et utiliser la valeur par défaut Performance du système Collecteur de l'ensemble des données. Demandez-lui de collecter des points de données toutes les 10 à 15 secondes et faites-le fonctionner pendant plusieurs jours.
Examinez également à quel endroit de votre flux de travail une machine plus rapide serait utile. Il est possible qu'une machine plus rapide ne fasse pas grand-chose. Par exemple, VS2010 peut être un gros consommateur de mémoire pendant les constructions, car il doit charger toutes les dépendances de votre projet. Je connais quelques endroits où l'on prend plusieurs vieux Pentium 4 et où l'on "externalise" les constructions.
La "lenteur" peut également être attribuée à l'application elle-même. Tous les programmes ne sont pas conçus pour profiter d'une grande quantité de mémoire libre. Certaines applications sont plutôt agressives en ce qui concerne le maintien d'un profil mémoire bas, mais préfèrent conserver les données sur le disque car l'espace disque est peu important.
