j'utilise torsmo qui me donne des indications sur mon système (Debian
sid dans ce cas) et notamment, la quantité de ram utilisée. Via torsmo,
elle est relativement faible, environ 150 Mo quand je lance firefox,
thunderbird et openoffice. Mais lorsque je fais un top dans la console,
j'ai une quantité proche des 400-450 Mo.
J'ai donc fait un test en n'utilisant rien si ce n'est xmms. J'ai donc
alors mon système qui tourne avec fvwm, torsmo, un terminal (mrxvt) et
xmms. Dixit torsmo, je suis aux alentours de 85 Mo. D'après top je suis
plus prêt des 450 Mo... J'ai mis un screen sur
http://zanton.free.fr/screen/top.jpg
Qui dois-je croire ? Autant 150 Mo me semble peu, autant 430 Mo me
semble beaucoup pour si peu de chose... Merci de votre aide.
Quand vous fermez un logiciel par exemple, contrairement à Windows, la mémoire n'est pas libérée. C'est débile de libérer la ram et ainsi d'avoir de la RAM non utilisée. De la RAM libre, c'est du gachi :) Si vous avez l'occasion, lancez un Windows, ouvrez l'explorateur, lancez
une recherche de "anus.*" sur un gros disque. Quand c'est terminé, lancez sur le même disque la recherche de "trouduc.*". Lancez un gros truc. Visual Studio par exemple. Fermez-le, puis relancez-le. Vous verrez ainsi s'il y a ou non un cache dans Windows. Et ça ne date pas d'hier. Sous DOS, il n'est pas immédiat d'écrire de façon fiable un programme qui par exemple écrit une image sur une disquette et compare ensuite la disquette et l'image. Enfin, l'écrire n'est pas difficile, mais ça se complique quand on s'apperçoit que la loupiote du lecteur reste éteinte pendant la vérification. Je précise qu'il ne s'agit pas d'un défaut du DOS mais d'un problème classique de programmation. -- Pierre
[...]
Quand vous fermez un logiciel par exemple, contrairement à Windows, la
mémoire n'est pas libérée. C'est débile de libérer la ram et ainsi
d'avoir de la RAM non utilisée. De la RAM libre, c'est du gachi :)
Si vous avez l'occasion, lancez un Windows, ouvrez l'explorateur, lancez
une recherche de "anus.*" sur un gros disque. Quand c'est terminé,
lancez sur le même disque la recherche de "trouduc.*".
Lancez un gros truc. Visual Studio par exemple. Fermez-le, puis relancez-le.
Vous verrez ainsi s'il y a ou non un cache dans Windows. Et ça ne date
pas d'hier. Sous DOS, il n'est pas immédiat d'écrire de façon fiable un
programme qui par exemple écrit une image sur une disquette et compare
ensuite la disquette et l'image. Enfin, l'écrire n'est pas difficile,
mais ça se complique quand on s'apperçoit que la loupiote du lecteur
reste éteinte pendant la vérification. Je précise qu'il ne s'agit pas
d'un défaut du DOS mais d'un problème classique de programmation.
--
Pierre
Quand vous fermez un logiciel par exemple, contrairement à Windows, la mémoire n'est pas libérée. C'est débile de libérer la ram et ainsi d'avoir de la RAM non utilisée. De la RAM libre, c'est du gachi :) Si vous avez l'occasion, lancez un Windows, ouvrez l'explorateur, lancez
une recherche de "anus.*" sur un gros disque. Quand c'est terminé, lancez sur le même disque la recherche de "trouduc.*". Lancez un gros truc. Visual Studio par exemple. Fermez-le, puis relancez-le. Vous verrez ainsi s'il y a ou non un cache dans Windows. Et ça ne date pas d'hier. Sous DOS, il n'est pas immédiat d'écrire de façon fiable un programme qui par exemple écrit une image sur une disquette et compare ensuite la disquette et l'image. Enfin, l'écrire n'est pas difficile, mais ça se complique quand on s'apperçoit que la loupiote du lecteur reste éteinte pendant la vérification. Je précise qu'il ne s'agit pas d'un défaut du DOS mais d'un problème classique de programmation. -- Pierre
