J´hallucine, en release, sous Visual C++ 6.0 ET visual C++ 2005, le std::vector l´emporte !! !

Regardez ce code !! !

1. include <vector>
2. include <stdio.h>
3. include <stdlib.h>
4. include <time.h>

1. define MAX 100000000 // ajoutez ou enlevez pour avoir des résultats significatifs

int main()
{
int* tab = new int[MAX];
std::vector<int> tab2;
tab2.resize(MAX);
int i;

clock_t t;
t = clock();
for(i=0;i<MAX;i++)
tab[i] = i+2;
printf("temps passe pour tableau : %d\n",clock()-t);

t = clock();
for(i=0;i<MAX;i++)
tab2[i] = i+2;
printf("temps passe pour vector : %d\n",clock()-t);

delete [] tab;
return 0;
}

Testé également sous Linux avec g++ et -O2
--> le vector est plus rapide !! !!

Quelqu´un peut m´expliquer ?

Salut,

J´ai testé ton code sur mon pc portable, chez moi le std::vector est beaucoup plus lent :/.

En debug c´est plus lent : mais essaie en release, et avec les options compilation -O2

ça y´est, je pense avoir trouvé pourquoi vector "paraissait" plus rapide qu´une simple allocation dynamique
ça viendrait du mécanisme de pagination.

Il m´a suffit de mettre une deuxieme fois le remplissage de tableau pour voir qu´il était bien plus rapide, et d´observer l´option "performance" pour voir l´évolution mémoire. (avec des system("pause") dans le programme)
Apres le new int[], je constate que la mémoire monte, MAIS que la mémoire physique utilisée ne monte pas.
Par contre, le resize() du vector fait monter la mémoire, et la mémoire physique.
La mémoire physique pour le tableau augmente pendant le for.

J´en conclus que le new n´alloue pas de mémoire physique (et c´est un vieux souvenir qui remonte, j´en avais entendu parler il y a fort longtemps en cours).
Il alloue de la mémoire virtuelle (a ne pas confondre avec le fichier Swap du disque dur), et cette mémoire n´est physiquement instanciée que quand on en a besoin (création de la page en RAM)
Donc c´est dans le for qu´il y a plusieurs de ces création de page, ce qui perd du temps.

Si je lance un deuxieme remplissage de tableau (j´écrase donc les premieres valeurs) alors le tableau étant déja physiquement en RAM, je n´ai pas a recréer des pages, donc la, je vais plus vite, et je vais plus vite que le vector (comme je l´attendais) (mais pas tellement plus vite)

Par contre, le vector, lui, lors du resize, a déja créé toutes ses pages en RAM, donc ne perdra pas de temps a le faire dans le for...
Si je relance un deuxieme remplissage sur le vector, j´obtiens le meme temps que le premier...

Ah ! l´informatique et les mécanismes internes, je trouve ça beau !!

Donc finalement, il vaut mieux utiliser des std::vector au lieu d´alloc dynamique ?

de toute manière ici, un bon compilo peut inliner l´appel à l´operator[] du vector et on se retrouve avec exactement le même code dans les deux cas, avec en plus une vérification du débordement pour le vector, qui prend un peu plus de temps, mais qui rend le programme beaucoup plus sûr.

La vérification du débordement est active en mode DEBUG, mais pas sur en mode release (effondrement de performances s´il faut vérifier a chaque fois)

Dans l´implémentation STL que j´ai sur mon poste, le resize alloue physiquement la mémoire, alors qu´un new cree de la mémoire virtuelle.
Il est intéressant de voir l´onglet performance du gestionnaire de taches, avec la partie "mémoire physique" pour bien voir ça

KeepSmile > non, je dirais que de toute façon, d´apres mon test, le "gain" de vector est perdu par la méthode "resize" : donc c´est kif-kif.
Le plus rapide reste, je pense, le tableau statique (si par exemple, tu alloues 3 entiers, et que ça ne sera jamais autre chose que 3), autant faire int t[3];

Ah ! l´informatique et les mécanismes internes, je trouve ça beau !!

moi je trouve ca compliqué

la verification de taille du vecteur est active dans toutes les configurations, le but meme etant de croitre automatiquement lorsque cela est necessaire.
quant a la difference d´alloc, on utilisera rarement des new ou allocs "bruts", une pratique courante etant d´implementer son heap manager pour gerer tout ca.