[Fichier] optimisation à l'ouverture

Bonjour,
Dans un programme que je suis amené à développer je dois passer par de gestion de fichier et je dois donc ouvrir et fermer des fichier un très grand nombre de fois(~1'000'000). Afin d'économiser du temps je souhaiterais optimiser ces traitements et connaitre les moyens les plus rapides de gérer les fichier.
Actuellement j'utilise les fonction du c fopen et autres. je souhaiterais donc savoir si utiliser les flux avec ifstream ou ofstream me ferait gagner du temps ou si il existe une méthode plus rapide pour les gérer.
Merci de votre aide.

Quel OS ?

D'une manière générale la manipulation de fichiers est du ressort du système. À priori, quelle que soit la méthode utilisée, ça reviendra toujours à faire un appel système - c'est ça qui prend du temps.

Donc tant que t'auras à ouvrir/fermer sans arrêt ces fichiers, il y a peu de chances que ça change en utilisant les flux...Tu dois vraiment travailler sur beaucoup de fichiers ou c'est simplement que l'ouverture/fermeture est mal placée (genre à l'intérieur de boucles) ?

Que veux-tu faire :

1 - ouvrir et fermer un même fichier plusieurs fois
2 - ouvrir et fermer un par un plusieurs fichiers
3 - les deux

Dans tous les cas, dis-nous ce que tu cherches exactement à faire, peut-être que d'autres solutions existent sans que tu en soupçonnes l'existence. A part ça, les flux C++ ne sont pas plus rapides que ceux du C. Si tu veux vraiment gagner en vitesse, il faudra utiliser les fonctions de bas niveau de ton système (CreateFile & co. sous Windows, creat & co. sous linux, etc.) à la place des fonctions de haut niveau de ton langage (fopen & co. en C, iostreams en C++, etc.), mais ce n'est pas évident.

Je n’ai plus l’habitude des fonctions du c, mais fopen et consorts ne sont pas bufferisés, alors que les iostreams le sont, non ?

Dans ce cas ça peut faire la différence (pour une utilisation « naïve » de ces méthodes).

Ils sont tous les deux par défaut bufferisés. Le mode de bufferisation peut être modifié à l'aide de la fonction setvbuf en C et ios::rdbuf et/ou streambuf::pubsetbuf en C++.

Merci pour vos réponses j'ai effectivement réussi a fortement diminuer le nombre d'ouverture de fichier en ouvrant mes fichier au debut du programme puis en le faisant passer en paramètre entre mes différentes méthodes ce qui permet à mon programme de s'exécuter en un temps beaucoup moins important.
Si il n'y a aucune méthode qui aille plus vite qu'un simple fopen je pense que le sujet est clos.

Salut,

Il me semble que sous unix, utiliser open et des file descriptor est plus rapide que fopen et les FILE*. Dans un petit utilitaire de lecture/écriture d'un fichier dans un pipe, les perf avaient beaucoup augmentées rien qu'en remplaçant les fopen par des open...
Par contre, comparé au stream C++ je ne sais pas.

Salut,

*Peut être* pourrais tu également gagner pas mal de temps en repensant completement ton algorithme... :

Au lieu de la séquence

1. ouvrir le fichier
2. lire / écrire une donnée dans le fichier
3. fermer le fichier
4. recommencer en (1)

tu pourrais, par exemple, envisager de placer l'intégralité du contenu dans une collection d'objet "qui va bien" pour gérer les informations.

tu en arriverais alors à une séquence de l'ordre de
ajouter l'information à écrire dans une collection d'objet

1. recommencer en (1)
2. ouvrir le fichier
3. écrire toutes les informations
4. fermer le fichier

ou de

1. ouvrir le fichier
2. lire l'information dans le fichier
3. ajouter l'information à la collection
4. recommencer en (2)
5. fermer le fichier

Il serait même, pourquoi pas, possible d'envisager de récupérer carrément l'intégralité du buffer du fichier ( cf la FAQ: Comment lire l'intégralité d'un fichier texte dans un buffer ?) dans la collection "qui va bien", de manière à limiter au mieux les acces disques.

En effet, ce qui prend vraiment énormément de temps, ce sont les accès disques, car il faut en permanence attendre que les tetes de lecture se positionnent correctement, puis que le disque termine le tour qu'il vient de commencer, et, enfin, que le bus de données arrive à suivre pour l'envois des données lues / écrites ;)

Citation:

---

Salut,

Il me semble que sous unix, utiliser open et des file descriptor est plus rapide que fopen et les FILE*. Dans un petit utilitaire de lecture/écriture d'un fichier dans un pipe, les perf avaient beaucoup augmentées rien qu'en remplaçant les fopen par des open...
Par contre, comparé au stream C++ je ne sais pas.

---

Je dois malheureusement travaillé sous xp donc pas de open mais merci quand même.

Citation:

---

Salut,

*Peut être* pourrais tu également gagner pas mal de temps en repensant completement ton algorithme... :

Au lieu de la séquence

ouvrir le fichier
lire / écrire une donnée dans le fichier
fermer le fichier
recommencer en (1)

tu pourrais, par exemple, envisager de placer l'intégralité du contenu dans une collection d'objet "qui va bien" pour gérer les informations.

tu en arriverais alors à une séquence de l'ordre de
ajouter l'information à écrire dans une collection d'objet

recommencer en (1)
ouvrir le fichier
écrire toutes les informations
fermer le fichier


ou de

ouvrir le fichier
lire l'information dans le fichier
ajouter l'information à la collection
recommencer en (2)
fermer le fichier

Il serait même, pourquoi pas, possible d'envisager de récupérer carrément l'intégralité du buffer du fichier ( cf la FAQ: Comment lire l'intégralité d'un fichier texte dans un buffer ?) dans la collection "qui va bien", de manière à limiter au mieux les acces disques.

En effet, ce qui prend vraiment énormément de temps, ce sont les accès disques, car il faut en permanence attendre que les tetes de lecture se positionnent correctement, puis que le disque termine le tour qu'il vient de commencer, et, enfin, que le bus de données arrive à suivre pour l'envois des données lues / écrites

---

J'ai utilisé ta 3e méthode et effectivement j'y ai nettement gagné en temps à l’exécution je mets 20 fois moins de temps(~5-10s vs 1min30) je vais maintenant tenter la lecture du fichier en global plutôt que caractère par caractère voir si je peut encore gagner 1 ou 2 seconde mais le temps d'exécution est déjà tout à fait acceptable.
Merci pour tout.