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

Version imprimable

17/11/2006, 12h28
TheSeb

Performances en lecture d'un fichier (std::getline)
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:

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.
17/11/2006, 13h02
olive_le_malin

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

@+
17/11/2006, 14h08
Invité

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'...
17/11/2006, 14h18
TheSeb

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.
17/11/2006, 14h21
Invité

Citation:

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...
17/11/2006, 14h53
koala01

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 :question:(parfois, une seconde, ca parrait vraiment long ;) :P)
17/11/2006, 14h56
Jean-Marc.Bourguet

Citation:

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.

Citation:

c'est encore de tester...

C'est mieux que de comparer l'assembleur.
17/11/2006, 14h58
Jean-Marc.Bourguet

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.
17/11/2006, 15h13
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 :!
17/11/2006, 15h22
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 (0.270 s)

mais plus de getline
17/11/2006, 15h32
Jean-Marc.Bourguet

Citation:

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.
17/11/2006, 15h35
Jean-Marc.Bourguet

Citation:

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.
17/11/2006, 15h55
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 :mrgreen:
17/11/2006, 16h40
Jean-Marc.Bourguet

Citation:

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 :mrgreen:

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.
17/11/2006, 18h18
HanLee

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:

ios::sync_with_stdio(false);

Qui désynchronise cout/cin avec printf/scanf. Mais peut-être que ça le fait aussi avec fstream ?
17/11/2006, 20h36
Invité

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 !
17/11/2006, 21h15
HanLee

Citation:

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 ?
17/11/2006, 23h11
loufoque

Commence par mettre ton compilateur à jour.
Les iostreams de MSVC6 sont loin d'être les plus performantes.
18/11/2006, 01h04
Luc Hermitte

* 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 ?
19/11/2006, 09h19
epsilon68

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+
19/11/2006, 11h34
loufoque

Chez moi que j'utilise std::string ou char* j'ai les mêmes performances... Ce qui est absolument normal.
19/11/2006, 11h40
Luc Hermitte

Qu'il y ait une perte de perf à cause de copies de 300mo de chaines, ce n'est pas forcément surprenant, surtout si tu compares par rapport à l'utilisation de vues (extraction de pointeurs, 0 copie)
19/11/2006, 11h41
epsilon68

j'utilise beaucoup de spilt et de map<string,string>
c'est clair que ca ne peut pas rivaliser avec des char*.
surtout quand les char * ne font que pointer vers la zone du fichier en memoire.....

cas particulier ? peut-etre mais sans cette optimisation on peut laisser tomber la version C++ (inutilisable!)

bonne nouvelle pour certains: Qt n'apporte aucune ameliorations la ou je pensais que l'implicit sharing etait performant :/ je suis decu
19/11/2006, 11h49
Luc Hermitte

Au mieux, utilises plutôt un truc type flex_string avec une police type vue pour la gestion de la mémoire et des copies -- cf le site d'Andrei Alexandrescu pour la flex_string.

L'implicit sharing n'est qu'un COW intrusif et atomique. Certaines implémentations de la std::string sont aussi des COW (atomique, je ne sais pas). La construction fonctionne aussi comme une copie, et n'agit en rien comme une vue. Cela va souffrir du même problème que la std::string, et au mieux on gagne les copies de manipulations maps.
19/11/2006, 12h06
epsilon68

Citation:

Envoyé par Luc Hermitte

L'implicit sharing n'est qu'un COW intrusif et atomique. Certaines implémentations de la std::string sont aussi des COW (atomique, je ne sais pas). La construction fonctionne aussi comme une copie, et n'agit en rien comme une vue. Cela va souffrir du même problème que la std::string, et au mieux on gagne les copies de manipulations maps.

justement j'attendais un gain pour les copies mais ce n'est pas du tout le cas, malheureusement. Je revise beaucoup mes avis en ce moment....

[edit] et la STL de Qt n'a pas de bonnes perf je trouve
19/11/2006, 12h16
etranger

si tu travail sous windows et que tu ne souhaite pas porter ton application, tu pourait tirer profit des API windows, j'avais une fois eu le meme probleme que toi, et j'avais fini par utiliser un truc du genre MapFileEx (je ne rappel pas tres bien).

Sinon pourquoi ne pas coder ta partie critique en C ?
19/11/2006, 13h25
epsilon68

les resultats pour C# peuvent quand meme faire reflechir.
ce qu'il y a de bien dans le c++, c'est qu'il y a toujours un moyen pour optimiser ....
19/11/2006, 14h13
loufoque

Citation:

j'utilise beaucoup de spilt et de map<string,string>

Ah d'accord... Moi je parlais du std::getline

Bonsoir,

Je déterre ce vieux poste car je dois lire un fichier de plus de 2 millions de lignes de plus de 60 caractères chacunes, sa taille est d'environ 241 Mo.

J'ai effectuer 2 tests :
-un test avec les flux C++ Fstream
-un test avec une version C à base de FILE

Etrangement la version C++ est la plus rapide contrairement aux précédents posts qui semblait prôner la toute puissance des lectures de fichier en C.

Ma machine de test est composé d'un processeur dual core Core2Duo 3GHZ, disque dur 7200 tr/min et de 2Go de ram, mon OS est Ubuntu 11.10 tournant sur un noyau Linux 3.0.0-15 generic avec gcc 4.6.1 avec l'options O0.

En ce qui concerne le comptage du temps, j'utilise une horloge Posix d'une précision de l'ordre de la nanoseconde.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 #include <iostream> #include <string> #include <fstream> #include <ctime> #include <cmath> #include <cstdio> using namespace std; void testFstream(string fileName) { fstream file(fileName.c_str()); string line; while (!file.eof()) { getline(file, line); } file.close(); } void testCstream(string fileName) { FILE* file; char line[100]; file = fopen(fileName.c_str(), "rw"); while (!feof(file)) { fgets(line, 100, file); } fclose(file); } int main() { struct timespec tBegin, tEnd; for (int i = 0; i < 10; ++i) { clock_gettime(CLOCK_REALTIME, &tBegin); //testFstream("test1"); testCstream("test1"); clock_gettime(CLOCK_REALTIME, &tEnd); cout << (tEnd.tv_sec * pow(10.0, 9) + tEnd.tv_nsec - (tBegin.tv_sec * pow(10.0, 9) + tBegin.tv_nsec)) / pow(10.0, 6) << " ms" << endl; } return 0; }
J'obtiens les résultats suivants :
-version C++ : environ 340 millisecondes
-version C : environ 476 millisecondes

Est ce qu'il y aurait moyen d'aller encore plus vite?

13/07/2012, 00h16
jabbounet
pourquoi 'rw' sur le fopen?

'r' est suffisant.

de plus il est possible d'éviter l'appel a feof car fgets retourne NULL en cas d'erreur ou si la fin du fichier est atteinte.
Code:

1 2 3 4 while (fgets(line, 100, file) { /* les traitement a venir */ }
Tu as au moins trois possibilité
- fgets largement abordé ici (implique un raisonnement par ligne)
- fread peut te permettre de lire plusieurs ligne à la fois mais il faudra abandonner le raisonnement par ligne pour espérer un gain par rapport a fgets.
- mmap qui te permet de monter le fichier directement en ram
en fonctions des cas (taille du fichier / os / contenu du fichier ....) une méthode peut être plus efficace qu'une autre.

Cependant plus le format du fichier est déterministe (par exemple chaque éléments à lire à une position fixe dans chaque ligne plus il sera possible d'optimiser le traitement en calculant par exemple l'a zone de la prochaine lecture.