Discussion :

[Ulrik18]

Bonjour,

Je travaille sur un projet et je veux avoir les meilleurs performances possibles. J'aimerais pouvoir lire le contenu d'un fichier texte en entier, avant d'appliquer des traitements sur les données lues.
Alors j'ai pensé à utiliser fseek pour aller jusqu'à à la fin du fichier afin de connaitre la taille du fichier, ensuite allouer la mémoire nécessaire à la lecture et enfin lire...

Je me demande alors si la complexité de fseek est fonction du nombre d'éléments présents dans le fichier à traverser, ou alors le SE a un moyen d'y aller en un temps constant (ou rapide).
je me dis que si la complexité est linéaire, autant lire au fur et à mesure ...

Merci de votre réponse.

[gangsoleil]

Bonjour,

Quelle est la volumetrie envisagee du fichier, et quel est le temps de traitement envisage ?

Si ton fichier n'est pas trop gros, avec un buffer de la bonne taille, tu couvriras 90% des cas, et les 10% restants seront plus lents (car plusieurs lectures).

[souviron34]

d'une part il y a des fonctions comme stat ou fstat pour avoir la taille d'un fichier.

Ensuite on peut utiliser les décalages SEEK_END pour aller diretement à la fin.

Enfin une recherche dichotomique sera de très loin le meilleur algorithme...

[Ulrik18]

Si ton fichier n'est pas trop gros, avec un buffer de la bonne taille, tu couvriras 90% des cas, et les 10% restants seront plus lents (car plusieurs lectures).

Les fichiers à manipuler feront 500 Ko tout au plus.

Ma question en fait est de savoir si une ligne comme :

Code :

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

1
2
 
fseek(f, 0, SEEK_END)

reviens à parcourir tous les caractères du fichiers jusqu'au caractère de fin de fichier (EOF).
Ce serait un peu moche, je trouve. Mais bon ...

Je vais peut-être essayer avec fstat comme m'a proposé souviron , mais je veux que le projet tourne autant sous windows... il y a fstat sous windows ?

Merci de vos réponses.

[gangsoleil]

Je vais peut-être essayer avec fstat comme m'a proposé souviron , mais je veux que le projet tourne autant sous windows... il y a fstat sous windows ?

Oui, fstat, quoi que POSIX, existe sous Windows. Ton probleme viendra plus des chemins de fichiers que des fonctions ( C:\Windows\my_docs VS /home/my_docs )

[Obsidian]

Je me demande alors si la complexité de fseek est fonction du nombre d'éléments présents dans le fichier à traverser, ou alors le SE a un moyen d'y aller en un temps constant (ou rapide). Merci de votre réponse.

La réponse est simple : ça dépend du médium que tu veux lire. Si c'est un disque dur, une disquette, ou un support type clé USB, la taille du fichier est consignée dans le système de fichiers. fseek(), en elle-même, ne fait aucune action autre que renseigner un champ dans ton descripteur de fichier pour dire où on en est. C'est lors de l'accès au disque (ou assimilé) que le système ira chercher le bon secteur.

Par contre, si tu travailles avec un vieux lecteur de bandes magnétiques, là, il faudra faire tourner les bobines dans un sens ou dans l'autre pour amener la tête de lecture à l'endroit désiré et si ton fichier n'a pas de table des matières, il faudra le lire en entier jusqu'à ce que l'on trouve le signal de fin. Donc, la complexité est proportionnelle à la quantité d'éléments qui te sépare de l'une des extrémités de ton fichier (multipliée encore par deux si tu souhaites ensuite regagner ta position initiale).

L'un des inconvénients de fseek(), en outre, est qu'il faut ton fichier soit ouvert pour en connaître la taille. Étant donné que la gestion des fichiers est l'une des premières raisons d'être d'un système d'exploitation, la seule raison de se passer de programmation système au profit de fseek() est de vouloir faire un programme ne s'appuyant que sur la norme C, exclusivement. Ce n'est pas forcément une bonne idée dans ce genre de cas…

Les autres inconvénients sont ici : http://www.developpez.net/forums/d64...e/#post3806352

[Trankille]

Setting the file position indicator to end-of-file, as with fseek(file, 0, SEEK_END), has undefined behavior for a binary stream (because of possible trailing null characters) or for any stream with state-dependent encoding that does not assuredly end in the initial shift state.

source [ISO/IEC 9899:1999]

D'après ce que j'ai pu voir ici, il vaut mieux utiliser fstat()

[Ulrik18]

Merci pour toutes vos réponses enrichissantes.
Finalement je crois que je vais utiliser fstat ....