Discussion :

[takout]

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 :

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

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);
}

[ManusDei]

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

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

[CGi]

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

[takout]

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.

[CGi]

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 :

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

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 :

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

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 !

[takout]

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 ?

[plxpy]

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 :

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

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 :

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

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 :

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

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:~$

[plxpy]

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 :

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

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:~$

[takout]

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 ?

[plxpy]

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).

[takout]

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.

[Bktero]

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.

[plxpy]

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 :

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

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 :

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

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'

[matafan]

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.