IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

mysterieux probleme ,memoire


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 91
    Par défaut mysterieux probleme ,memoire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    for(int i=0;i <500000; i++)
    {
    	JSValue* val = new JSValue(2);			
    	delete val;
    }
    est plus rapide que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    for(int i=0;i <500000; i++)
    {
    	JSValue* val = new JSValue(2);			
    }
    Pourtant on a une instruction en plus, on appelle le destructeur de JSValue.
    Comment se fait-il que c'est plus rapide?
    Merci

  2. #2
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 967
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 967
    Par défaut
    Noe,

    Le compilateur a sans doute vu que tu détruis immédiatement le pointeur, et il est probable qu'en fait il ne fasse rien (à vérifier en allant voir le code généré).

    D'autre part, réserver toute cette mémoire (2ème code) sans la libérer est une mauvaise idée, même si c'est pour un test (stocker les pointeurs initialisés dans un tableau, et faire une boucle pour les libérer).

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 91
    Par défaut
    je pense pas que le compilo n'alloue rien.
    car la difference de temps entre les 2 n'est pas enorme.
    C'est un peu plus rapide avec le delete, et je comprend pas pourquoi.
    c'est peut l'algo du new pour trouver la place memoire ou allouer.
    Quand on fait le delete il trouve plus facilement la place ou allouer.

  4. #4
    screetch
    Invité(e)
    Par défaut
    dans le cas ou tu appelles delete, new réutilise le bloc que tu viens juste de libérer, et remet l'objet exactement au meme endroit. c'est basiquement gratuit.
    Si tu ne le liberes pas, new doit d'abord allouer la mémoire, ce qui es tres lent

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 91
    Par défaut
    comment est-tu sur que l'os alloue au meme endroit?
    Et puis quand tu fait delete, la memoire est liberée, donc doit etre aussi réallouée, non?
    Je saisi pas vraiment

  6. #6
    screetch
    Invité(e)
    Par défaut
    je le sais parce que je travaille avec des allocateurs mémoire.
    l'allocation de la mémoire se fait en plusieurs etapes. disons que tu veux allouer un bloc. En appelant new, toute une batterie de choses vont etre faites.

    new maintient une liste chainée de blocs de memoire libres. lorsque tu alloues, il commence par verifier dans la liste si un bloc de cette taille existe. SI il existe quelque part dans la liste, le bloc est detaché de la liste et renvoyé.
    Sinon, si il y a un gros bloc dans la liste, new va d'abord le couper en deux, un bloc de la bonne taille a renvoyer, et un autre bloc (le reste, dont on a pas besoin) qu'il met de coté.
    Si il n'y a pas de gros bloc a couper, alors new demande un gros bloc de mémoire a l'OS (mettons un meg). il coupe ce gros bloc de memoire en deux, un tout petit bout de la taille qui convient (pour le donner a l'appelant) et un gros bout qu'il garde pour plus tard, qu'il met dans la liste.


    Lorsque tu liberes de la memoire, tout ce que new fait c'est mettre ce bloc en tete de liste, et c'est tout.

    Lorsque tu fais donc new, delete, new, delete, etc
    potentiellement le premier new va etre tre couteux (il faut demander de la memoire a l'os, couper le bloc, etc)
    puis tu liberes ce bloc, qui est placé en tete de liste
    puis tu demandes un nouveau bloc de la meme taille, et la c'est fastoche, tu viens de mettre un bloc qui convient exactement en tete de liste. c'est quasi gratuit.

    Dans le cas ou tu fais new, new, new, etc
    alors le premier new est long, le deuxieme, il coupe un gros bloc, le troisieme, coupe un troisieme bout dans le gros bloc, etc etc, c'est plus couteux que de juste renvoyer la tete de liste.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. manipulation de std::vector probleme memoire
    Par angediablo dans le forum SL & STL
    Réponses: 20
    Dernier message: 03/08/2006, 19h10
  2. Probleme Memoire avec Bytebuffer sosu eclipse
    Par jlassiramzy dans le forum Eclipse Java
    Réponses: 15
    Dernier message: 31/07/2006, 11h01
  3. [JVM] Problème mémoire
    Par javaDev dans le forum Général Java
    Réponses: 5
    Dernier message: 16/03/2006, 11h40
  4. [ASE]probleme memoire: select dans une insert
    Par SegmentationFault dans le forum Sybase
    Réponses: 2
    Dernier message: 16/08/2005, 12h20
  5. Eclipse UML, JVM - Problème mémoire - Mandrake ?
    Par chat hotplug dans le forum Applications et environnements graphiques
    Réponses: 5
    Dernier message: 02/08/2005, 14h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo