Discussion :

[theawe]

Bonjour,

Je dispose d'une fonction qui doit parcourir un fichier se composant de différents blocs de lignes de textes, délimités par les chaînes de caractères "DEBUT" et "FIN", comme ceci :

Code :

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

1
2
3
4
5
6
7
8
DEBUT
// Données
FIN
DEBUT
// Données
FIN
[...]

La fonction est appelée, elle ouvre le fichier, et lorsqu'un bloc est trouvé, elle effectue quelques traitement puis s'arrête : elle est donc appelée autant de fois qu'il y a de blocs de données.
J'ai inclus dans le code le fait qu'à chaque bloc, je sauvegarde la position de l'offset en lecture dans le fichier dans une variable ULONGLONG, avant de retourner ce dont j'ai besoin (j'utilise la classe CStdioFile pour gérer le parcours). Lors d'un appel ultérieur de la fonction, le fichier sera ouvert à la position donnée à la fin de la lecture du bloc précédent.

Je suis passé par ce système puisqu'auparavant, le fichier était toujours parcouru depuis le début, ce qui rendait l'application assez lente. Le fichier était alors géré avec des pointeurs FILE * et le parcours se faisait via les fonction fscanf(), gets().

Le problème est que je me retrouve avec une fonction encore plus lente qu'auparavant.

Connaitriez-vous un moyen d'optimiser ce parcours ?
Merci par avance.

[3DArchi]

Salut,
Peux-tu montrer ta fonction de lecture ?
Es-tu sûr que le problème soit bien là ?

[bacelar]

Pourquoi ouvrir plusieurs fois le même fichier ?

La lecture séquentielle de bloc de 8Ko devrait être optimal avec l'utilisation automatiques des différents caches (cache disque, cache OS, cache applicatifs.

[theawe]

En fait, j'utilise le parcours du fichier pour une fonction d'ouverture de documents. Les commandes récupérées sont ensuite traitées et exécutées graphiquement.
En testant deux parcours différents, l'un avec CStdioFile et des méthodes de sauvegardes de position de l'offset spécifiques, l'autre avec des FILE * et des méthodes de sauvegardes de position de l'offset spécifiques, encore une fois, je me suis aperçu que le parcours était bien plus rapide avec la seconde méthode.

[farscape]

salut,
je suis étonné que l'api C soit plus rapide que CStdioFile,
CStdioFile travaille directement avec les api 32 (comme CFile) ,il n'y a pas plus directe (sauf l'api 32).
suivant la taille du fichier il vaut mieux le lire d'un seul bloc dans une CString par exemple et effectuer les recherches directement dedans ça ira plus vite..

[theawe]

salut,
suivant la taille du fichier il vaut mieux le lire d'un seul bloc dans une CString par exemple et effectuer les recherches directement dedans ça ira plus vite..

Je travaille avec des fichiers qui ont une taille égale à plusieurs dizaines de MO.
Si jamais ça n'avait pas été le cas, tu penses que travailler sur un objet CString au lieu d'un fichier, en sachant que chaque action sur l'objet sera un appel de méthode CString pourrait être plus rapide ?

Concernant la rapidité du parcours :
Je pense qu'en fait ce qui est plus long avec CStdioFile c'est le repositionnement de l'offset du fichier.

[farscape]

travailler en mémoire directement ira toujours plus vite que dans un fichier.
en ce qui concerne le positionnement que ce soit l'api c ou CStdioFile les deux appels l'api 32 .
il doit y avoir une autre raison.
tu peux aussi agrandir le cache mémoire alloué au stream de l'objet avec un Setvbuf:

Code :

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

1
2
 
setvbuf(m_pStudioFile->m_pStream, NULL, _IOFBF,MEMORYALLOC);