Discussion :

[tachaout]

j'ai un vecteur de listes que je veux concaténer. J'ai testé un push_back élément par élément et un splice. Résultat: le push_back est plus rapide ce qui m'étonne. Des explications ?

PS: je n'ai pas besoin de garder les listes VL[x]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
void Merging(list<vector<int> > &L, vector<list<vector<int> > > &VL){
        unsigned k=VL.size();
	for(int x=0; x<k; x++){
		//L.splice(L.end(), VL[x]);
		for(list<vector<int> >::iterator it=VL[x].begin(); it!=VL[x].end(); it++){
			L.push_back(*it);
		}
	}
}

Merci

[Arzar]

Bonjour,

C'est en effet extrêmement curieux. Je dirais même presque impossible vu que splice() a été conçu exactement pour satisfaire ce cas et doit normalement se résoudre à une poignée d'opérations ultra-cheap (réassigner 5 ou 6 pointeurs dans la plupart des cas), alors que chaque push_back fait une copie entière des noeuds de la liste à concaténer, et donc doit allouer autant de nouveaux nœuds en tapant dans le tas.

Est-ce que le problème ne viendrait pas plutôt de la manière dont tu mesures ?

Désolé, je ne connais pas ton expertise la dessus, donc au cas où, voici quelques banalités sur l'art compliqué du bench : (mais bon on ne sait jamais, perso j'ai si souvent pris des vessies pour des lanternes à cause de bench mal fait... )

1) Toujours mesurer en release.

2) La durée à mesurer doit être supérieure à environ 50ms, sinon la mesure n'est pas significative sur la plupart des OS (trop de fluctuations)

3) Toujours refaire les mesures de nombreuses fois. (car il arrive que l'on se prenne des hiatus complètement incompréhensible, comme si l'ordinateur avait eu le hoquet )

4) Si sur visual studio 2005 ou 2008, bien penser à définir _SCL_SECURE et _HAS_ITERATOR_DEBUGGING à zéro et à lancer le bench avec ctrl+F5 et pas F5 pour éviter d'attacher le debuggeur.

5) Enfin attention aux effets de cache tordus. Je me souviens m'être fait avoir en beauté une fois sur un bench dont le but était aussi de comparer une méthode A et une méthode B. Je me suis rendu compte bien plus tard qu'il suffisait d'inverser l'ordre d'appel pour changer complètement les résultats ! Et en fait c'était toujours la deuxième appelée dans l'ordre chronologique du bench qui était nettement plus rapide que la première. Il me semble que c'est parce que la première méthode venait "chauffer" le cache avec des données qui étaient réutilisées juste après.

[tachaout]

Oops, désolé

je m'étais trompé dans mes mesures. Effectivement, un splice et bien plus
rapide que plusieurs push_back.
En tous les cas, les conseils d'Arzar sont bien utiles