Discussion :

[Musix]

Bonjour,

Je souhaite créer et remplir un vecteur de strings à partir d'un fichier texte. J'ai suivi le conseil de la faq :
http://cpp.developpez.com/faq/cpp/?p...ream_iterators

Mon fichier contient 300000 lignes de 2 colonnes. Soit 600000 strings à stocker. Pour faire simple, disons que la taille ne varie pas (en pratique elle varie). Voici le code que j'ai écrit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// ouvre le fichier
ifstream file("fichier.txt",ios::in) ;
 
// crée le vecteur de strings
vector<string> list ;
 
// réserve la mémoire
int size = 600000 ;
list.reserve(size) ;
 
// remplit le vecteur
copy(istream_iterator<string>(file),istream_iterator<string>(),back_inserter(list)) ;
 
// ferme le fichier
file.close() ;

J'obtiens bien un vecteur de 600000 strings, pas de problème. Mon souci est dans le temps d'exécution : 1.4 secondes. Je trouve que c'est anormalement lent. Alors j'ai testé avec un tableau de strings :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// ouvre le fichier
ifstream file("fichier.txt",ios::in) ;
 
// crée le tableau de strings
int size = 600000 ;
string * list = new string[size] ;
 
// remplit le tableau
for ( int i = 0 ; i < size ; i++ )
	file >> list[i] ;
 
// ferme le fichier
file.close() ;

Cette solution avec le tableau de strings s'exécute en 0.9 secondes. Je pensais que le vecteur était mieux adapté, et qu'il serait plus rapide. J'aimerais savoir si c'est "normal" ou si j'ai mal compris quelque chose. Je ne suis pas sûr de bien faire la réserve de mémoire avec le vecteur.

[Klaim]

D'abord, comment as-tu effectué tes mesures?

[Musix]

Pour mesurer le temps d'exécution, j'ai utilisé la fonction clock(). Par exemple, pour mesurer la première solution :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Début de la mesure
clock_t t1 = clock() ;
 
// Ce que je veux mesurer
ifstream file("fichier.txt",ios::in) ;
vector<string> list ;
int size = 600000 ;
list.reserve(size) ;
copy(istream_iterator<string>(file),istream_iterator<string>(),back_inserter(list)) ;
file.close() ;
 
// Fin de la mesure
clock_t t2 = clock() ;
cout << (float)(t2-t1)/CLOCKS_PER_SEC << endl ;

Je n'ai pas fait de boucle pour moyenner le temps sur plusieurs itérations. Mais j'ai exécuté plusieurs fois ce bout de code, et j'obtiens sensiblement (à 0.1 sec près) les mêmes valeurs.

[Astraya]

SI tu compares la fonction cpy à ta fonction for, tu verras que copy effectue des choses en plus.

Code :

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

1
2
3
4
5
6
template<class InputIterator, class OutputIterator>
  OutputIterator copy ( InputIterator first, InputIterator last, OutputIterator result )
{
  while (first!=last) *result++ = *first++;
  return result;
}

De plus le back_inserter rajoute un appel de fonction pour chaque ligne. Sur 100 ligne aucune différence, sur 30000 ça joue. Après ça vas dépendre de l'optimisation faite par le compilateur, a vérifié dans le code machine, ce n'est qu'une hypothèse.

le copy + iterator + back_inserter n'est pas une combinaison de performances, mais de facilité d'utilisation et de relecture.

[r0d]

As-tu testé avec les options d'optimisations adéquates? (Il ne sert à rien de faire des tests de rapidité en mode Debug par exemple).

[Luc Hermitte]

std::vector::reserve() est ton ami -- et c'est ce que fait le tableau.
Tu as les deque aussi sinon.

[3DArchi]

Salut,

[...]

Remarque de méthode :
Tu fais varier au - 3 paramètres :
std::vector => new []
std::copy => for
std::istream_iterator =>operator>>

Comment peux tu dire que tes différences de perf ne tiennent qu'au changement std::vector vs new ? Comment peux-tu garantir que cela ne vient pas du changement d'itérateurs de flux en lecture directe ?

[Musix]

Merci pour toutes vos réponses

Première faute : j'étais en mode Debug
Deuxième faute : tu as raison 3DArchi, trop de paramètres varient à la fois.

J'utilisais déjà la fonction reserve(). Aussi bizarre que cela paraisse, ça améliore peu les performances. J'ai testé en mode release cette fois :

Code :

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

1
2
3
4
t1 = clock();
vector.reserve(size) ; // Test 1 : sans // Test 2 : avec
copy(istream_iterator<string>(file),istream_iterator<string>(),back_inserter(vector)) ; 
t2 = clock() ;

Je passe de 0.56 sec à 0.48 sec en ajoutant la réserve.

Quant à la comparaison vector vs [], j'obtiens désormais les mêmes ordres de grandeur que rmdak. Lorsque les deux structures sont remplies par l'opérateur >> les performances sont quasiment identiques.

[rmdak]

J'utilisais déjà la fonction reserve(). Aussi bizarre que cela paraisse, ça améliore peu les performances.

La ré allocation de mémoire lorsqu'un vector est plein est censée être "intelligente" au sens ou elle réserve non pas une case supplémentaire mais plutôt double (pas sur exactement de la quantité) la taille du vector en mémoire.

Sa me rappel une entrée de la FAQ Stroustrup ou il parle du reserve vers la fin : http://www2.research.att.com/~bs/bs_...low-containers