Nombre de lignes dans un fichier

Bonjour à tous,

J'ai écrit un programme qui compte le nombre de lignes dans un fichier.
Mon souci c'est que comme mes fichiers contiennent beaucoup de données, le programme met un certain temps.
J'aimerais savoir s'il existe une méthode plus rapide (toujours en C) pour compter les lignes dans un fichier ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int LigneFichier(FILE *fichier) {   int nrow=0; char c;   rewind(fichier);     while((c=fgetc(fichier)) != EOF){   if(c == '\n') ++nrow; } rewind(fichier); return(nrow); }

---

Tu peux utiliser fgets plutôt que fgetc, par exemple.

C'est probablement pas optimal, mais ça devrait être déjà meilleur.

Le charger par blocs avec fread et compter les '\n' dans les blocs.
ça éviterait les appels aux fonctions fgets ou fgetc.

Le problème avec fgetc c'est qu'il faut je connaisse le nombre d'éléments dans chaque ligne il me semble.
Pour fread je n'ai pas trop compris son utilisation dans mon cas.

fread sert à lire les fichiers binaires, mais un fichier texte est un fichier binaire (l'inverse n'est pas focement vrai).
Ton problème est un problème de rapidité, c'est pour cela que je t'ai proposé fread. Tu fais des boucles sur les blocs lus pour compter tes '\n'

Fait les tests avec ces deux codes :

avec getc :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <stdio.h>   int main(void) { int nrow=0; char c; FILE* MyFile = NULL; MyFile = fopen("fichier.txt", "r"); if(MyFile) { while((c=fgetc(MyFile)) != EOF){ if(c == '\n') ++nrow; } printf("%d", nrow); fclose(MyFile); } return 0; }

---

avec fread :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

#include <stdio.h>   #define BUFSIZE 4096   int main(void) { int i; int clu; int nrow=0; char buffer[BUFSIZE]; FILE* MyFile = NULL; MyFile = fopen("fichier.txt", "r"); if(MyFile) { while(clu = fread(buffer, sizeof(char), BUFSIZE, MyFile)) { for(i=0; i<clu; i++) if(buffer[i]=='\n') nrow++; } printf("%d", nrow); fclose(MyFile); } return 0; }

---

Tu verras la différence !

ah ok!
Merci!
j'ai une question et si la taille de mes lignes dépasses la taille du Buffer qu'est ce qui se passe ?

La version GNU de wc ("wc - print newline, word, and byte counts for each file") utilise aussi cette approche (fread).

Par contre, pour compter le nombre de '\n', c'est memchr (string.h) qui est utilisé.

Ici, ça revient à remplacer :

Code:

---

1 2 3 4

while(clu = fread(buffer, sizeof(char), BUFSIZE, MyFile)) { for(i=0; i<clu; i++) if(buffer[i]=='\n') nrow++; }

---

par

Code:

---

1 2 3 4 5 6 7 8 9

while (clu = fread(buffer, sizeof(char), BUFSIZE, MyFile)) { char *p = buffer; while (p = memchr(p,'\n',(buffer+clu)-p)) { p++; nrow++; } }

---

On y gagne encore quelque chose :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

plx@sony:~$ time ./cgi_orig Bureau/POINTS_LIAISONS.TXT 4677482 real 0m1.151s user 0m1.016s sys 0m0.128s plx@sony:~$ plx@sony:~$ time ./cgi_sauce_gnu Bureau/POINTS_LIAISONS.TXT 4677482 real 0m0.237s user 0m0.104s sys 0m0.132s plx@sony:~$ plx@sony:~$ time wc -l Bureau/POINTS_LIAISONS.TXT 4677482 Bureau/POINTS_LIAISONS.TXT   real 0m0.245s user 0m0.096s sys 0m0.144s plx@sony:~$

---

Citation:

---

et si la taille de mes lignes dépasses la taille du Buffer qu'est ce qui se passe ?

---

buffer ne contiendra pas toujours un caractère '\n' et, dans ce cas, la boucle de comptage (for (i=0, ... ou while (p = memchr(...) n'incrémentera pas nrow.

En passant BUFSIZE à 40 (plus petit que les lignes de mon fichier), on obtient le même nombre de lignes, seules les performances s'en ressentent (c'est normal) :

Code:

---

1 2 3 4 5 6

plx@sony:~$ time ./cgi_sauce_gnu Bureau/POINTS_LIAISONS.TXT 4677482 real 0m0.826s user 0m0.648s sys 0m0.176s plx@sony:~$

---

Citation:

---

buffer ne contiendra pas toujours un caractère '\n' et, dans ce cas, la boucle de comptage (for (i=0, ... ou while (p = memchr(...) n'incrémentera pas nrow.

En passant BUFSIZE à 40 (plus petit que les lignes de mon fichier), on obtient le même nombre de lignes, seules les performances s'en ressentent (c'est normal)

---

Je pense qu'il y a un souci si le dernier caractère lu n'est pas une fin de lignes.
On fait comment pour palier à ce cas ?

Citation:

---

Je pense qu'il y a un souci si le dernier caractère lu n'est pas une fin de lignes.

---

Non. Pourquoi ?

Tu pourrais, de la même manière (en remplaçant '\n' dans le test ou dans memchr), compter le nombre de 'a' de ton fichier par exemple.

Dans l'algo, le '\n' ne tient pas un rôle particulier. C'est parce que '\n' équivaut à une ligne qu'on s'intéresse à ce caractère. fread lit des octets quelconques. Il ne se cale pas sur tel ou tel caractère (comme fgets).

J'ai pas compris !
Dans certain fichier il se peut que le dernier caractère lu n'est pas \n.
Cela cause un problème car on associe à une ligne un \n.

Si ton fichier se termine par \n, alors tu as une ligne vide à la fin de ton fichier... qui ne se termine pas par \n.

Citation:

---

J'ai pas compris !
Dans certain fichier il se peut que le dernier caractère lu n'est pas \n.
Cela cause un problème car on associe à une ligne un \n.

---

Ok. J'avais compris "dernier caractère lu" par "dernier caractère lu ... lors de l'appel à fread", pas dernier caractère du fichier. Ma réponse (tu peux la reprendre) était faite dans ce contexte.

Je dirais que ça va dépendre de l'éditeur. Je prends ce que j'ai sous la main, en tapant deux lignes "blabla" mais sans faire de <RETURN> à la fin de la deuxième

Les extensions correspondent à l'éditeur (Text Wrangler est un éditeur sous MacOSX).

Sous Linux :

Code:

---

1 2 3 4 5 6 7 8 9

plx@sony:~$ od -c blabla.vi 0000000 b l a b l a \n b l a b l a \n 0000016 plx@sony:~$ od -c blabla.gedit 0000000 b l a b l a \n b l a b l a \n 0000016 plx@sony:~$ od -c blabla.eclipse 0000000 b l a b l a \n b l a b l a 0000015

---

et sous MacOSX :

Code:

---

1 2 3 4 5

pascal@kermit:~$ od -c blabla.text_wrangler 0000000 b l a b l a \n b l a b l a 0000015 pascal@kermit:~$

---

Encore une histoire de poteaux et d'intervalles ...

Ce qui est sur, c'est que dans le code de wc GNU, c'est bien le nombre de caractères '\n' qui est pris en compte. Si tu veux blinder, ajoute 1 si le dernier caractère lu (dernier caractère du fichier !) n'est pas '\n'

Ce qui pose "problème" ce n'est pas la dernière ligne, c'est la première ligne. Le nombre de lignes d'un ficher c'est le nombre de retours à la ligne, plus 1 (pour la première ligne) si le fichier contient au moins un caractère.