Discussion :

[philmor34]

J'ai fait un test simple pour savoir quel conteneur STL était le plus rapide quand on marchais dans ceux ci avec un itérateur, entre vector et list.

J'ai donc crée un vecteur de 10 entier et une liste de 10 entier.
Ensuite, j'ai fait créer une boucle for qui boucle 1000000 de fois, et dans cette boucle for, j'ai marcher sur tous les éléments du vecteur et de la liste.

Code :

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

1
2
3
4
5
6
7
8
9
clock_t vector_ticks = clock();
 
for (int i = 0; i < 1000000; i++)
{
  for (vector<int>::iterator it = v.begin (), itend = v.end (); it != itend; it++)
  {
  }
}
vector_ticks = clock() - vector_ticks;

Je ne répète pas le code pour la liste qui est identique, sauf pour une liste.
J'ai imprimé les résultats sur la console:

pour le vecteur (pour mon ordinateur): 15382
Pour la liste (pour mon ordinateur): 15288

la liste est donc un peut plus rapide.

Ensuite, me suis demander ce que cela ferais si je marchais le même nombre de fois dans un tableau.

Code :

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

1
2
3
4
5
6
for (int i = 0; i < 1000000; i++)
{
  for (int j = 0; j < 10; j++)
  {
  }
}

résultat: 16

Uniquement 16 battements sur mon ordinateur. contre un peut plus de 15000 pour la liste et le vecteur.

Je me suis dis que la différence était trop importante, donc j'ai essayé quelque chose d'autre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
vector<int>::iterator it = v.begin (), itend = v.end ();
 
vector_ticks = clock();
 
for (int i = 0; i < 1000000; i++)
{
  for (; it != itend; it++)
  {
  }
}
vector_ticks = clock() - vector_ticks;

Résultat:

vecteur: 94 (mais monte parfois à 123)
liste: 93 (mais monte parfois à 128)
tableau: 16 (reste toujours à 16)

parfois le vecteur est à 98 et la liste a 120, et parfois c'est le vecteur à 120 et la liste à 98. Donc je pense que l'utilisation d'un tableau ou d'une liste pour aller sur tous les éléments est la même chose.

faite donc bien attention ou vous placez le code pour définir vos iterator

Edit: Ceci est en mode debug

[JolyLoic]

Edit: Ceci est en mode debug

Et donc ne présente pas trop d'intérêt... Normalement, les temps devraient être bien plus resserrés en release.

[loufoque]

J'ai fait un test simple pour savoir quel conteneur STL était le plus rapide quand on marchais dans ceux ci avec un itérateur, entre vector et list.

Pas besoin de faire de test, c'est forcément vector.

[yan]

Attention

Code :

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

1
2
3
4
5
6
7
 
for (int i = 0; i < 1000000; i++)
{
  for (; it != itend; it++)
  {
  }
}

Tu être quasiment sur que la plupart des compilots ne vont pas l'exécuter en release, car tu n'y fait rien.

[r0d]

Il est à noter que ce type de test est plus délicat qu'il n'y parait. Plusieurs écueils sont à éviter:

1. Comme l'a dit JolyLoic, il faut compiler et exécuter en release, avec les options d'optimisation, sinon ça n'a pas réellement de sens.

2. Comme l'a dit mongaulois, il faut s'assurer que ton code fait quelque chose, sinon il ne sera pas exécuté. Et là attention, parce que même si tu fais quelque chose, parfois c'est quand-même zappé par le compilo (par exemple si tu modifies une variable qui n'est pas utilisée ensuite), et il faut faire attention à ce que ce que tu fais n'ajoute pas une dimension (encore plus) aléatoire à l'exécution, comme typiquement un accès à une ressource (à noter que la console est une ressource).

3. Spécifier le compilateur et l'implémentation de la STL utilisée. Chaque compilo et chaque implémentation de la STL a ses spécificités, il est est parfaitement possible d'obtenir des résultats différents de l'un à l'autre.

4. Bien prendre en compte le contexte de l'OS. Lunix, windows, mac? (chaque os a également ses spécificités, et encore une fois, on peut obtenir des résultats différents de l'un à l'autre). Les programmes en cours d'exécution, etc. En fait, pour être parfaitement exacts, ces tests devraient être exécutés sur un pc où aucun programme n'est en cours d'exécution (ce qui est impossible dans la pratique, et donc pour compenser il faut jouer sur la quantité des tests effectués: au plus on en fait, au plus l'effet aléatoire des ressources prises par les autres processus en cours seront minimisés).

5. Bien prendre en compte le matériel et l'utilisation qui en est faite. Selon le type de processeur, en particulier, on peut obtenir des résultats qui varient également. Peut-être pas dans ce cas-là, mais parfois ça peut changer pas mal.

Et j'en oublie certainement.

Bref, tout ça pour dire que ces tests sont plus difficiles qu'il n'y parait, et c'est pour ça qu'il est si difficile d'en trouver qui soient réellement complets.

My cent.