( N * fprintf ) ou ( N * strcat + fprintf ) ?

? ( N * fprintf ) ou ( N * strcat + fprintf ) - C - Programmation

Marsh Posté le 10-05-2006 à 17:19:55    

Re salut
 
J'ai mon programme qui fait une centaine de fprintf pour écrire des champs dans un fichier texte en sortie pour chaque enregistrement lu en entrée (de 100000 à 500000 enregistrements en entrée).
 
Est-ce que remplacer (100 fprintf) par (100 strcat + 1 fprintf) peut faire gagner beaucoup en performances ?
 
Là j'ai un process qui traite 400000 enregistrements en 32 heures .... [:alvas]  Je pense que le client va pas aimer  [:aztechxx]

Message cité 1 fois

---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)
Reply

Marsh Posté le 10-05-2006 à 17:19:55   

Reply

Marsh Posté le 10-05-2006 à 18:00:35    

jipo a écrit :

Re salut
 
J'ai mon programme qui fait une centaine de fprintf pour écrire des champs dans un fichier texte en sortie pour chaque enregistrement lu en entrée (de 100000 à 500000 enregistrements en entrée).
 
Est-ce que remplacer (100 fprintf) par (100 strcat + 1 fprintf) peut faire gagner beaucoup en performances ?


Je ne pense pas. Par contre, il ne fait pas ouvrir et fermer à chaque fprintf(), ni balancer un fflush(stdout).... C'est probablement ça qui prend du temps...
 
Le mieux : tu ouvres, tu ecris les 4000000000000000 fprintf(), tu fermes.
 
Si c'est pas possible essaye de trouver un compromis...


Message édité par Emmanuel Delahaye le 10-05-2006 à 18:02:23

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 10-05-2006 à 18:13:57    

Citation :

(100 fprintf) par (100 strcat + 1 fprintf)


 
est-ce que tu te sers des capacitée de formatage de fprintf ? ou t'en sers juste pour pousser ses chaines ?

Reply

Marsh Posté le 10-05-2006 à 19:38:57    

faut faire attention en enchainant les strcat sur la meme chaine, sa taille recalculée à chaque appel (alors qu'il suffirait de conserver un pointeur sur la fin), a par ca les fonctions de string.h sont forcement plus rapide
 

Citation :

Là j'ai un process qui traite 400000 enregistrements en 32 heures .... [:alvas]  Je pense que le client va pas aimer  [:aztechxx]


 
tu as profilé ton code ? ca represente combien en Mo ces 400000 enregistrements ?

Reply

Marsh Posté le 11-05-2006 à 10:07:30    

Bonjour,
 
En fait j'ai fait des tests avec :
1) N*fprintf  
2) N*strcat+1fprintf.
10000 enregistrements en entrée traités en :
1) 45 minutes  
2) 56 minutes  
 
Donc le fait d'avoir remplacé les N fprintf par des strcat m'a fait perdre du temps ...
Donc je garde la solution initiale


---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)
Reply

Marsh Posté le 11-05-2006 à 10:09:34    

skelter : bonne idée ...
Je ne sais pas si j'aurais le temps de la mettre en oeuvre ... mais j'y penserai
 
Quant au fait de profiler le code ... je sais pas trop ce que cela peut apporter ni comment le mettre en oeuvre ... quels outils ? Intéret ?
 
Merci


---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)
Reply

Marsh Posté le 11-05-2006 à 10:16:59    

Pour l'instant je travaille avec un fichier en entrée de 75000 enregistrements : soit 4,2 Mb
Voici la fonction qui lit chaque enregistrement. C'est de l'artisanat de débutant ... donc si vous voyez que cela peut être largement amélioré, faites le moi savoir ...
 

Code :
  1. #define NB_CHAMPS_INPUT1 15
  3. ...
  5. struct Input1
  6. {
  7.   long champs[NB_CHAMPS_INPUT1];
  8.   char enregistrement[200];
  9. };
  11. ...
  13. /****************************************************************************************************/
  14. /*! \fn struct Input1 *lireInput1(FILE* f)
  15. \brief Lit un enregistrement du fichier input1  
  16.  
  17. \param f : descripteur du fichier input1 ouvert
  18.  
  19. \return rend le pointeur sur le tampon en cas de lecture sans erreur, ou NULL  dans le cas de fin de fichier ou d'erreur.  
  20. *****************************************************************************************************/
  21. struct Input1 *lireInput1(FILE* f)
  22. {
  24. char zone[20];
  25. char* reste;
  26. char* sep;
  27. char* test;
  28. int i;
  30. /* Lecture d'un enregistrement du fichier input1 */
  31. test = fgets(Input1Courant.enregistrement, 200, f);
  33. if (test != NULL)
  34.  {
  35.  reste = Input1Courant.enregistrement;
  37.  for(i=0; i < NB_CHAMPS_INPUT1; i++)
  38.   {
  40.   sep = strstr(reste,";" );
  42.   if (sep == 0)
  43.    {
  44.    strcpy(zone,reste);
  45.    Input1Courant.champs[i] = atol(zone);
  46.    break;
  47.    }
  48.   else
  49.    {
  50.    strncpy(zone, reste, sep - reste);
  51.    zone[sep - reste] = '\0';
  52.    Input1Courant.champs[i] = atol(zone);
  53.    reste = sep+1;
  54.    }
  55.   }
  57.  return(&Input1Courant);
  58.  }
  59. else
  60.  {
  61.  return(NULL);
  62.  }
  63. }


---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)
Reply

Marsh Posté le 11-05-2006 à 12:44:57    

"strncpy(zone, reste, sep - reste)"... Pourquoi fais-tu une copie de chaque champ avant de les convertir en entiers avec "atol" ? Si c'est juste pour avoir un "zéro terminal", place ton zéro dans la chaîne source (Input1Courant.enregistrement) en écrasant le point-virgule et fais le "atol" directement dessus...
 
EDIT : je crois que c'est ainsi que travaille "strtok"...


Message édité par spotaszn le 11-05-2006 à 12:50:12
Reply

Marsh Posté le 11-05-2006 à 16:21:28    

si le volume des donnée est de l'ordre de quelque mega, la seul operation d'ecriture devrais avoir une duree de l'ordre de quelque seconde (dans le pir des cas sur le commun des disque dur), ou alors tu ecris sur un autre type de peripherique.
 
donc tu as reelement besoin de profiler, avec gprof si tu compiles avec un compilateur gnu (gcc, g++, ...), pour voir le temps passer dans chaque fonctions par exemple et determiner en un coup d'eil celle aurait reelement besoin d'etre optimimisee
 
c'est possible qu'avec strcat ca soit plus lent mais comme je l'avais dit enchainer des strcat sur la meme chaine est tres inefficace
 
regarde du coté des extensions gnu (si tu utilises un compilateur gnu), je pensais que ce probeleme etait resolu mais il y a un exemple (source de la fonction concat) dans la doc de la glibc
http://www.gnu.org/software/libc/m [...] catenation

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed