Performances en lecture d'un fichier (std::getline)

**TheSeb** · 17/11/2006, 12h28

Bonjour,

J'ai besoin de lire et parser un fichier d'une taille de 11 Mo contenant 180 000 lignes.
J'ai utilisé le code suivant pour effectuer un test de temps de lecture :

Code :

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

1
2
3
std::ifstream geomFile(name);
std::string myLine;
while(std::getline(geomFile, myLine));

Cela prend environ 5 secondes.
Je trouve cela un peu lent et je voulais savoir si c'est normal que ce soit aussi lent ou bien si cela vient de la fonction getline(), du compilateur visual c++6 ou autre chose...
Merci.

PS : mon ordinateur est récent.

**olive_le_malin** · 17/11/2006, 13h02

as-tu essayé avec d'autres fonctions ?
fonctions C --> fgets() par exemple ... pour comparer les perf ?

@+

Invité · 17/11/2006, 14h08

il y a peut etre d'autres solutions ; cela dépend de ce que tu veux faire du contenu du fichier...

par exemple, lire le fichier en entier, brut de brut, et compter le nombre de '\n'...

**TheSeb** · 17/11/2006, 14h18

J'ai pas trop envie de retourner au langage c et les char * mais bon s'il faut ça pour les performances ...

Le fichier il faut que je le lise en entier, parce que c'est un fichier de géométrie 3D que je charge dans une structure de données.
Je me pose la question de lire tout d'un coup dans un buffer mais c'est peut être un peu bourrin.

Invité · 17/11/2006, 14h21

Envoyé par TheSeb

Je me pose la question de lire tout d'un coup dans un buffer mais c'est peut être un peu bourrin.

la meilleure facon de comparer les performances, outre de comparer l'assembleur généré, c'est encore de tester...

**koala01** · 17/11/2006, 14h53

Salut,

Le problème des performances en lecture d'un fichier est multiple:

En vrac, et rien qu'au niveau du matériel, on peut estimer que cela peut dépendre de la position du fichier par rapport aux tetes de lecture du disque (si le fichier se trouve sur "le bord du disque" et les tete de lecture "au centre"), de son degré de fragmentation éventuelle, de la rapidité de rotation du disque, de sa disponibilité ou non dans un cache quelconque, d'un acces "direct" au fichier (il est physiquement sur le disque dur de l'ordinateur au départ duquel on tente d'y accéder) ou non, des autres acces au disque nécessités par d'autres applications...

Ensuite, de fait, cela peut etre du au programme lui-même, mais, en tout état de cause, tu ne dois pas te baser sur "la premiere lecture" du fichier en question...

Il y a fort à parier que, si tu faisait une boucle qui appelle la lecture totale du fichier, et que tu l'appelais un nombre suffisant de fois, tu verrais un "temps de lecture moyen" tres largement inférieur, meme en utilisant le meme compilateur...

Enfin, il n'est pas exclu qu'un compilateur puisse créer un code exécutable plus "propre" ou "plus efficace" qu'un autre... mais là, encore une fois, il faudrait faire une batterie de tests, dans des conditions similaires, pour s'en assurer...

Sois aussi attentif au fait que, dans les 5 secondes, tu ne précise pas si le temps de (re)compliation ou le délais entre la (re)compilation et le lancement effectif de l'application sont comptés...

Enfin, il faut être particulièrement prudent... S'agit-t-il d'un "délais estimé" ou d'un délais calculé précisément

(parfois, une seconde, ca parrait vraiment long

)

**Jean-Marc.Bourguet** · 17/11/2006, 14h56

Envoyé par toxcct

la meilleure facon de comparer les performances, outre de comparer l'assembleur généré,

Pour des IO, comparer l'assembleur ne me semble pas etre une bonne methode.

c'est encore de tester...

C'est mieux que de comparer l'assembleur.

**Jean-Marc.Bourguet** · 17/11/2006, 14h58

Quelle est la proportion du temps des IO par rapport au temps de traitement? Parce que meme s'il y a moyen de le faire en 0.005s mais que le temps de traitement derriere est de 4 jours... tu auras gagne 5s sur 4 jours, cad rien.

**TheSeb** · 17/11/2006, 15h13

Ce qui m'embête oui c'est ça, c'est que je passe plus de temps à lire le fichier qu'à le traiter.
Pour un ordre de grandeur :
- 10 sec de traitement du fichier,
- 5 sec de lecture,
- 5 sec de traitement sachant que la fonction split que j'utilise à certains endroits me fait perdre bien 3 sec. (récupérée sur www.codeproject.com)
en tout cas merci pour tout.
Je continuerai à chercher mais là j'ai plus trop de temps à perdre là dessus :!

**epsilon68** · 17/11/2006, 15h22

moi aussi je trouve que le getline est tres tres lent.
57000 lignes = 1.7 secondes.

ce qui doit etre un peu pres comme toi.

solution: j'ai mappé le fichier en memoire (22 Mo)
resultat: immediat (0.270 s)

mais plus de getline

**Jean-Marc.Bourguet** · 17/11/2006, 15h32

Envoyé par TheSeb

Ce qui m'embête oui c'est ça, c'est que je passe plus de temps à lire le fichier qu'à le traiter.
Pour un ordre de grandeur :
- 10 sec de traitement du fichier,
- 5 sec de lecture,
- 5 sec de traitement sachant que la fonction split que j'utilise à certains endroits me fait perdre bien 3 sec. (récupérée sur www.codeproject.com)
en tout cas merci pour tout.
Je continuerai à chercher mais là j'ai plus trop de temps à perdre là dessus :!

C'est quoi ton traitement? Utiliser perl ou quelque chose du genre ne serait pas mieux?

Sinon, passer par la lecture brute (rdbuf()->*get*) plutot que de perdre du temps a construire des strings qui n'ont pas l'air de servir a grand chose.

**Jean-Marc.Bourguet** · 17/11/2006, 15h35

Envoyé par epsilon68

moi aussi je trouve que le getline est tres tres lent.
57000 lignes = 1.7 secondes.

ce qui doit etre un peu pres comme toi.

solution: j'ai mappé le fichier en memoire (22 Mo)
resultat: immediat

Oui mais le contenu n'est pas encore en memoire. Il ne sera mis en memoire qu'a la demande, suivant l'algo du swapper. Ce peut etre un gain si les acces sont consecutifs et que le swapper peut profiter du temps de traitement.

**epsilon68** · 17/11/2006, 15h55

j'ai mappé le fichier en memoire:
j'ai lu le fichier en une seule fois dans un grand char * alloué par new avec la taille du fichier.

... pas de swapper

**Jean-Marc.Bourguet** · 17/11/2006, 16h40

Envoyé par epsilon68

j'ai mappé le fichier en memoire:
j'ai lu le fichier en une seule fois dans un grand char * alloué par new avec la taille du fichier.

... pas de swapper

Quand je lis "mapper un fichier en memoire", je pense a mmap ou equivalent sous Windows. C'est alors bien le swapper qui intervient pour faire la lecture.

**HanLee** · 17/11/2006, 18h18

Je dis peut être une connerie mais on sait jamais.
Je sais qu'on peut accélérer significativement les entrées/sorties console en C++ avec l'instruction suivante :

Code :

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

ios::sync_with_stdio(false);

Qui désynchronise cout/cin avec printf/scanf. Mais peut-être que ça le fait aussi avec fstream ?

Invité · 17/11/2006, 20h36

quand bien même cela était vrai (je ne connais pas du tout cette méthode), ça ne fera pas tourner ton disque dur plus vite !

**HanLee** · 17/11/2006, 21h15

Envoyé par toxcct

quand bien meme cela etait vrai (je ne connais pas du tout cette méthode), ca ne fera pas tourner ton disque dur plus vite !

C'est sûr, mais est-on sûr que sa méthode exploite à fond la vitesse de lecture du disque dur ?

**loufoque** · 17/11/2006, 23h11

Commence par mettre ton compilateur à jour.
Les iostreams de MSVC6 sont loin d'être les plus performantes.

**Luc Hermitte** · 18/11/2006, 01h04

* La synchronisation de stdin avec stdout n'a rien à voir avecla choucroute
* Les flux sont effectivement connus pour être moins efficaces que les I/O C. D'un autre côté ils permettent énormément plus de choses : locales localisés, filtrages à la volée, ... Pour des solutions typesafes, rapides, mais bridées, il y a des approches comme celle de FAStreams
* Tout charger d'un coup peut définitivement être très efficace.

Bref, quel est le traitement à réaliser sur ces lignes ?

**epsilon68** · 19/11/2006, 09h19

justement, moi je suis en train de realiser un petit outil qui travaille sur des csv et globalement faire un pivot sur les colonnes... (split, std::map etc)

et ce n'est pas les flux qui sont lents mais les "string"
d'ailleurs je suis revenu aux char* de loin les plus efficace.

je mets le fichier dans une zone memoire et je reference les petits bouts de celle-ci par apres. c'est terriblement efficace!!!

aussi je dois dire que je l'ai fait sur C#, tout bete sans chercher a optimizer,
et j'ai otenu un temps de 21 s / 90 Mo de memoire.

le faire pareil en C++ j'obtiens un temps de ~30 s / 300 Mo de memoire
(utilisation des string et des std::map<string,string> etc)

avec optimisation : C++ 14 s / 40 Mo de memoire ( 4.5 secondes de traitement, 9.5 s d'ecriture du fichier )
(mise en memoire du fichier, utilisation des char*, std::map<char*,char*,functor_case_insentive> )

je vais maintenant faire quelques optimisation de coté c# pour que le benchmark soit equitable....

J'ai été franchement étonné par C# qui donne de vraiment bons resultats
sans se soucier de quoi que ce soit .... voila qui donne plutot a reflechir...

[edit] j'ai meme essayé de le faire avec Qt en pensant que son implicit sharing allait changer du tout au tout ..... laisser tomber il n'y a rien a voir

[edit2] faire attention a bien ouvrir le fichier en binary sinon il y a des conversion de fin de ligne parfois tres lente (sur Qt ca été flagrant, avec les iostream un peu moins)

[edit3] j'ai mis les quelques optimisations dans le C# et c'est maintenant 17 s. l'occupation memoire n'a pas changé

a+

Performances en lecture d'un fichier (std::getline)

SL & STL C++

Discussions similaires

Partager

Partager