Discussion :

[GyZmoO]

Bonjour a tous !

Je me demande quelque chose, dans mon application, je dispose de 3 répertoires contenant des fichiers textes. 2 de ces répertoires contiennent 100 fichiers témoins et le dernier contient 150 fichiers à analyser .

L'algo ressemble a ça :

Pour chaque fichier f du répertoire de fichiers a analyser Faire
Ouvrir fichier du 1er répertoire témoin
Ouvrir fichier du 2nd répertoire témoin
... traitement ...
Fermer(fichier du 1er répertoire)
Fermer(fichier du 1er répertoire)

En gros, ce que j'essaye de dire, c'est que j'ouvre et je ferme les fichiers témoins 150 fois. Et mon problème c'est que ça prend beaucoup de temps a l'exécution, donc je me demandais, si en ouvrant une seule fois les fichiers et en les fermant tous d'un coup je gagnerai beaucoup de temps? (Au lieu d'ouvrir et de fermer 150 fois...) . Je ne l'ai pas encore fait, car faudrait modifier une grosse partie du code, et avant de ma lancer je préfère avoir des avis.

Merci .

[souviron34]

ça ça ne devrait sans doute pas changer grand'chose mais 1 question :

Que veux-tu faire exactement ????

Parce que ouvrir et fermer 100 fichiers (et en plus le faire à chaque fichier à traiter) me semble une erreur de conception... . Ou d'organisation...

[GyZmoO]

Hmmm c'est pas tout a fait une erreur de conception. J'ai été obligé de faire comme ça, parce que je me sert d'un algo de compression (LZW) que j'ai récupéré sur le net, et qui prenait en entrée le nom du fichier a compresser et non pas le FILE *. Du coup l'algo de compression prend le nom, ouvre le fichier, fait le traitement, et le ferme. C'est pour ça... Donc je me demande si ça vaut le coup de modifier ce code pour qu'il prenne en entrée directement le FILE *. Mais bon le code fait peut être 700~800 lignes, donc ça m'emm..... de le modifier si au final, je ne gagne pas beaucoup niveau temps d'exécution.

[Edit] Et puis au début, je ne devais pas tester autant de fichier (150 ) d'un coup, mais plutot une dizaine ou vingtaine [/Edit]

[DaZumba]

Donc je me demande si ça vaut le coup de modifier ce code pour qu'il prenne en entrée directement le FILE *.

C'est impossible. As-tu bien compris ce qu'est un pointeur ?

[GyZmoO]

Comment ça c'est impossible????

J'ai une fonction de ce style

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
void fun(char *fileName)
{
   ...
  fd =    fopen(fileName);
  if (fd != NULL)
     {
       blabla;
     }
 
  fclose(fd);

Je peux faire en sorte qu'elle devienne comme ça :

Code :

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

1
2
3
4
5
 
void fun(FILE *fd)
{
   blabla;
}

Et c'est la fonction appelant qui s'occupe de l'ouverture/fermeture du fichier !!

[souviron34]

et tu es sous quelle plateforme ??

800 lignes et tu trouves que c'est trop gros pour regarder à modifier ?????

[GyZmoO]

Win xp. Mais non je sais bien que c'est pas grand chose, c'est juste que j'ai une dead line qui se rapproche relativement vite !!! Donc vous pensez que ça serait une bonne chose que j'ouvre tous les fichiers d'un coup, que je fasse tous les traitements, et que je ferme tous d'un coup? (Biensur c'est une bonne chose de faire comme ça) Mais je vais y gagner beaucoup de temps ou ça va être invisible????

[DaZumba]

Comment ça c'est impossible?

Ah, j'avais compris que tu voulais passer un pointeur sur FILE en argument de ligne de commande. En interne, evidemment, c'est possible. Desole pour cette erreur.

Pour ton probleme, si tu as N fichiers a traiter, tu dois faire N fopen() et N fclose(). Par contre, si la fonction ouvre le fichier, n'en traite qu'une partie, le referme pour refaire la meme chose plus tard, sur le meme fichier, alors il est preferable de laisser le fichier ouvert. Ceci dit, il faudrait identifier la portion de code qui coute cher avant de faire des optimisations. Peut etre que c'est le traitement (operations d'I/O comprises) qui est long, auquel cas le cout d'un fopen/fclose est negligeable.

[souviron34]

Et c'est la fonction appelant qui s'occupe de l'ouverture/fermeture du fichier !!

ça changera strictement rien....

[GyZmoO]

Je dois mal m'exprimer.

A l'heure actuelle mon programme est comme ça :

- dans le main je fais appel a ma fonction de compression, qui ouvre le fichier témoin, compresse le fichier témoin, et le ferme. Mais ça, ça se passe 150 fois, et j'ai 100 témoins. En gros, j'ouvre et je ferme 100 fichiers différents mais 150 fois.

Ce que je voudrais faire :

- dans mon main, ouvrir tous les fichiers témoins une seule fois. Faire appel a ma fonction de compression. Et fermer tous les témoins d'un coup.

C'est plus clair?

[Edit]

Ah, j'avais compris que tu voulais passer un pointeur sur FILE en argument de ligne de commande. En interne, evidemment, c'est possible. Desole pour cette erreur.

Pour ton probleme, si tu as N fichiers a traiter, tu dois faire N fopen() et N fclose(). Par contre, si la fonction ouvre le fichier, n'en traite qu'une partie, le referme pour refaire la meme chose plus tard, sur le meme fichier, alors il est preferable de laisser le fichier ouvert. Ceci dit, il faudrait identifier la portion de code qui coute cher avant de faire des optimisations. Peut etre que c'est le traitement (operations d'I/O comprises) qui est long, auquel cas le cout d'un fopen/fclose est negligeable.

C'est moi qui m'exprime mal, mais voila je sais pas ce qui coute cher

[/Edit]

[souviron34]

Je dois mal m'exprimer.

A l'heure actuelle mon programme est comme ça :

- dans le main je fais appel a ma fonction de compression, qui ouvre le fichier témoin, compresse le fichier témoin, et le ferme. Mais ça, ça se passe 150 fois, et j'ai 100 témoins. En gros, j'ouvre et je ferme 100 fichiers différents mais 150 fois.

C'est bien ce que je disais... Je pense erreur de conception....

Pourquoi ne pas sauvegarder à la première passe les fichiers témoins compressés, puis s'en servir 149 fois, et les détruire à la fin ??

mais voila je sais pas ce qui coute cher

Si tu utilises gcc, compile avec l'option -pg et après l'exécution tu lances gprof, ou bien -p et après l'exécution prof, et tu auras la répartition en temps et le nombre d'appels et tout et tout...

[GyZmoO]

Oué je vais faire comme ça ! Je devrais quand même y gagner ! Merci pour le tuyau avec gcc, la je travaille avec C::B et minGw, mais je le saurai maintenant, merci

[souviron34]

Oué je vais faire comme ça ! Je devrais quand même y gagner ! Merci pour le tuyau avec gcc, la je travaille avec C::B et minGw, mais je le saurai maintenant, merci

ben normalement mingw devrait comprendre ça aussi...