Discussion :

[kaiser92]

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

[droggo]

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).

[kaiser92]

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.

[screetch]

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

[kaiser92]

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

[screetch]

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.

[kaiser92]

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

tu veux dire tout ce que fais delete, c'est bien ca?

[screetch]

oui pardon (chuis fatigué moi...)

[kaiser92]

ok, donc cela veut dire que faire new, new, new, delete, delete, delete, (ce que fait un garbage collector), est plus lent que new, delete, new, delete, new, delete...
C'est bien intriguant tout ca.

[Goten]

Ben non, c'est pas intriguant, on t'as expliqué comment était géré l'allocateur en interne. Je vois pas ce qu'il reste d'intrigant...

[kaiser92]

Ce qui est intriguant est que tu peux lire dans des FAQs sur les garbage collector qu'un GC n'est pas plus lent qu'un code ordinaire sans GC, ou la tu fais les new, delete a ta guise.
Et puis la je m'apercois que c'est nécessairement plus lent.
J'ai trouvé un GC sur internet en c++, qui fait GC_NEW au lieu de new, il fait toujours new, new, new, jusqu'a ce qu'on atteigne un seuil, dans ce cas le GC se met en marche et delete tous les pointeurs qu'il trouve.
Cela equivaut a new, new, new, delete, delete, delete.

[3DArchi]

Tout dépend comment fonctionne la gestion mémoire.
A mon avis fait le test suivant :
1/ Alloue tes 500000 objets d'un coup.
2/ détruit les
3/ fait tes séquences allocations/delete ou allocation seulement puis delete à la fin.
J'ai l'intuition que l'écart entre les 2 va grandement diminuer.

Ensuite, c'est vraiment le mécanisme de gestion mémoire qui joue. Dans un temps assez reculé, j'avais bossé sur une plateforme où les allocations étaient faites dans des pools de blocs préalloués et de taille dépendant du pool avec une liste vers les blocs libres. Faire des séries de new+delete ou faire des série new puis de delete prenait le même temps.

[kaiser92]

J'en arrive donc a la question suivante, est ce qu'avec un pool 500.000 new est plus rapide que 500.000 new sans pool manager?

[3DArchi]

J'en arrive donc a la question suivante, est ce qu'avec un pool 500.000 new est plus rapide que 500.000 new sans pool manager?

La question ne se pose pas vis à vis du new ou du malloc mais de savoir comment fonctionne ton gestionnaire de mémoire.

[kaiser92]

oui en fait je pose plein de question car je crée 500.000 objets et je voudrais que ca aille le plus vite possible.
Avoir un pool manager permet d'eviter que la VAS soit fragmentée, mais est-ce que oui ou non cela augmente la vitesse d'allocation plutot que 500.000 new fait avec l'operateur new sans pool.
Merci

[Goten]

Du point de vu du C++, la bonne optimisation que tu pourrais avoir serait d'utiliser un allocateur plus performant si t'es objets sont de petites tailles.
C'est une collection d'objet que t'alloue?

[kaiser92]

Oui c'est des objets de tres petite taille, ou pourrais-je trouver un bon allocateur tu penses?
C'est gentil de m'aider en tout cas.
Merci

[Goten]

Je connais que celui de loki qui est vraiment bien pensé amha. Il y'a un gain considérable de mémoire sur l'allocation de plein de petits objets. (celui par défaut est pas performant sur les petits objets).
Je crois qu'il y'en a aussi du côté de boost, mais j'avoue ne pas les connaitre et donc ne pas pouvoir les comparer, quelqu'un ayant déjà utilisé la solution de boost pourra peut être t'aider plus.

ps : c'est boost.pool la bibliothèque concernée.

[screetch]

sans aller jusqu'a bidouiller l'allocateur, un new Class[500000] va te créer 500000 objets prets a l'emploi en un minimum de temps, ca ne suffit pas ?
sinon, un gros malloc, et des "placement new" dedans

[Goten]

Justement je lui est demandé si c'est une collection ou si c'est indépendant. Si c'est une collection tout d'un bloc c'est ta solution la plus rapide sans aucun soucis. Sinon il peut utiliser un allocateur adapté (et c'est pas une bidouille)