Défrag de la RAM: Mythe ou réalité?

[Lunarshade]

Salut

 

 

 

J'ai utilisé a peu prêt tout les progs pour libérer de la Ram qui existe et j'ai fini par entendre parler que la Ram, sa ne se défragmente pas.. Y'a quelqu'un qui pourrait m'éclairer sur le sujet?

 

 

 

Merci!

[lamasu]

bah non la ram ca se fragmente pas donc ca se defrag pas non plus !

 

 

 

tu peux toujours en liberer avec les commandes fournies sur ce site dans astuces ou avec tweak all.

[Moby]

Techniquement en fait si, voici l'explication:

 

en programmation orienté objet (C++, java, etc...) on utilise des pointeurs qui sont en fait des variables (contenant une adresse mémoire) de la mémoire renvoyant à d'autres variables par le biais de cette adresse mémoire. Le problème est qu'en C (pas en java), si on détruit un pointeur sans détruire la variable pointée, la variable reste en mémoire et ne peut pas être récupérée... En java il existe un "garbage collector" chargé de récupérer cet espace automatiquement, mais la plupart des progs sont en C ou dérivés!

 

Donc quand de nouvelles données arrivent en mémoire, les adresses contenant des variablees non pointées ne peuvent pas être utilisées => d'où trous = fragmentation!

 

Maintenant, les programmes dont tu parles sont chargés de récupérer la mémoire bouffée par ces variables non pointées, et ça peut être utile. Tu peux tester la performance en regardant ta mémoire libre avant et après (win2000).

 

voilà, j'éspère que j'ai été assez clair, c'est pas une notion facile à comprendre!

 

A+

[Lunarshade]

Ouais, c'est clair vu que j'ai compris...

 

 

 

Merci

[Seiju]

Je viens mettre mon grain de sel un petit peu.

 

Je doute que le défragmenteur de RAM agisse de cette facon car sinon ce serait un garbage collector et non un défragmenteur.

 

Je pense plutot qu'il se contente de relocaliser les segments de mémoire alloués par les applications pour qu'ils soient contigus en RAM (et cela ne fonctionne que si le code adresse sa mémoire en relatif, ce qui est la grande majorité des cas). Car n'oublions pas que sous Windoz, pour les applis en C, C++, Java et les autres langages quelqu'ils soient (car n'oublions pas que c'est le système d'exploitation qui accorde à une application la mémoire qu'il demande et non chaque application qui fait ce qu'elle veut), la mémoire n'est pas allouée octet par octet au niveau du système d'exploitation mais par segments virtuels alloués au lancement (code, pile et tas) ou au fur et à mesure de ses besoins (allocation dynamique) et qui sont dédiés à l'application et protégés car accessibles seulement par le applications qui les allouent ou leurs "pères" (c'est pour ca que l'on voit des erreurs de "segmentation violation" quand un prog se permet d'accéder à de la RAM qui appartient à une autre application).

 

Normalement, sur tout système d'exploitation multi-tâche protégé qui se respecte, quand l'application tombe (stoppée par l'utilisateur ou par le système car elle execute des instructions erronées), les segments de mémoire qui lui sont ratachés sont détruits avec elle, donc un garbage collector n'est pas necessaire puisqu'il existe déjà au niveau du système d'exploitation.

 

Alors pourquoi, sous Windoz, on ne retrouve pas toute sa mémoire aprés avoir lancé une application et l'avoir stoppée ?

 

Tout simplement parce que Windoz garde en mémoire les bibliothèques de fonctions partageables entre applications (les DLLs) même si aucune application lancée ne les utilises (pour des raisons de performance).

 

Et aussi parce que Windoz est tellement instable que si un programme arrive à déstabiliser le système (ce qui n'est pas bien difficile à faire sous 98, un peu moins facile sous NT/2k), le système ne libère pas la mémoire qui est allouée par ce programme.

 

 

 

Quant-à l'intérét de ce genre d'applications .... ca peut jouer pour des machines avec peu de mémoire et qui swappent beaucoup car c'est plus rapide pour le système de relocaliser 1 seul bloc de mémoire contenant tous les segments alloués d'une application dans le cache (quand celle-ci passe en IDLE que de le faire en plusieurs fois. Et encore, si Windoz ne se contente pas de déplacer segment par segment la mémoire en question sans chercher à savoir s'il ne pourrait pas tout déplacer d'un coup.

 

Il faut aussi tenir compte des ressources utilisées par le "défragmenteur" et voir s'il n'apporte pas plus de problèmes qu'il en résout (Windoz est déjà assez instable comme ca sans rajouter ce genre d'applis je trouve).

 

 

 

Seiju

[nulobez]

Seiju a raison. Il ne faut pas confondre l'espace d'adressage d'un programme (qui peut faire son propre ménage ) avec les requêtes d'allocation mémoire au système, qui seront de tailles très différentes selon les applications.Sous unix, il existe couramment une tâche de récupération des pages "perdues" .... mais c'est vrai c'est pas simple ....

[Lunarshade]

Ah, je vois que c'est vraiment pas si simple maintenant!

[examan]

Salut, tout le monde.

 

Je voulais savoir si on peut libérer de la RAM quand elle est utilisée à 55%.

 

ça ne risque pas de planter?

 

J' ai une barrette de 128 SDRAM PCI 133Mhz.

 

 

 

Merci de me répondre.

[Lunarshade]

Non, sa ne devrait pas poser de problème.

[LeAngus]

 

Alors pourquoi, sous Windoz, on ne retrouve pas toute sa mémoire aprés avoir lancé une application et l'avoir stoppée ?

 

Tout simplement parce que Windoz garde en mémoire les bibliothèques de fonctions partageables entre applications (les DLLs) même si aucune application lancée ne les utilises (pour des raisons de performance).

 

 

 

 

Juste une petite question:

 

 

 

Windows garde les dll em memoire. Si on supprime ces derniers on libere de la ram (donc a priori des performances ) mais dans le cas ou Win aurait besoin d'un Dll qu'on vient justement d'effacer il devrait une nouvelle fois le charge.

 

 

 

Et je me demandais donc si le gain etait reel dans ce genre de situation ?

 

(et aussi si win conserver tous les dll ou seulement les generiques)

 

 

 

Voila, voila

 

 

 

A+

 

 

 

Angus kifepeutetreunpeuchier