Discussion :

[mikadev]

Salut je souhaiterai afficher dans mon application, le pourcentage d'un fichier lu j'ai essayer ca :

pourcentage <- ligneLu.length() / fichier.length() * 100

problème ça ne fonctionne pas pour certain gros fichier au bout d'un moment les lignes lu font plus que le totale.

[thelvin]

Normal puisque toutes les lignes ne font pas la même taille et que la taille du fichier n'indique pas le nombre de lignes, mais le nombres d'octets.

Il ne faut donc pas compter les lignes, il faut compter les octets. Malheureusement, pour compter les octets tout en lisant des lignes, il faut le faire, soit de manière très lente (lire caractère par caractère jusqu'à tomber sur une fin de ligne, en buffurisant peu,) soit de manière imprécise (considérer qu'on en est, non pas à la position de la dernière ligne, mais à la position du dernier octet gardé dans le buffer. Ce qui peut être faux si, par exemple, chaque ligne prend 5 minutes à traiter, et que les 5 dernières lignes sont toutes dans le buffer, le fichier étant considéré à 100%, et pourtant il reste 25 minutes de traitement.)
Et c'est assez compliqué à faire, aussi.

[mikadev]

merci de ta réponse néanmoins existe-il une solution fiable ?

[thelvin]

Oui, mais je n'en ai pas trouvé sur Internet. Je les ai programmées moi-même.
Cela dit, si tu connais les encodages possibles des fichiers à lire, et qu'ils sont tous rétrocompatibles ASCII, c'est assez simple : il suffit d'utiliser directement FileInputStream et de compter les octets lus. Pour lire une ligne, tu lis simplement des octets jusqu'à trouver une fin de ligne, et tu gardes les suivants de côté pour la prochaine lecture.

Edit : ok, je retire ce que j'ai dit, même comme ça ça reste assez difficile.

[dumbl]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
BufferedReader br=new BufferedReader(new FileReader(url))
int compteur=0;
while((ligne=br.readligne)!=null){
compteur++;
}
br.close()
br=new BufferedReader(new FileReader(url))
int j=0;
while ((ligne=br.readligne)!=null){
j++;
System.out.println("pourcentage : "+j/i+"%");
}

Pour la méthode octet je ne sais pas, mais c'est sans doute la meilleur.

[thelvin]

Oui enfin, lire le fichier deux fois juste pour pouvoir afficher une barre de progression la deuxième fois... Bon, il y a des cas où ça se justifie, mais c'est pas en général -_-°.

[mikadev]

oui effectivement la on est sur mais comme le dit thelvin tu lit le fichier deux fois et si il y a trop de lignes bonjour le temps perdu sinon j'ai toujours pas trouvée qq chose de fiable en dehors de ca

[thelvin]

J'ai regardé un peu ce que font les autres, et je crois bien qu'ils utilisent la méthode imprécise : celle qui compte le nombre d'octets qui ont été lus et buffurisés, mais pas qui ont été traités (et qui donc risque d'estimer que 100% a été fait, alors qu'il reste genre 5 lignes dans le buffer qui n'ont pas encore été traitées.)
En effet ils restent coincés aussi longtemps à 100% qu'aux autres pourcentages, or en principe, à 100%, on a fini et la suite est immédiate. Je suppose que c'est acceptable dans le monde réel.

Guava propose CountingInputStream qui peut te dire à tout moment combien d'octets tu as lus dans le fichier.

Ça ressemble à ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
long fileSize = file.length();
 
try(
  CountingInputStream stream = new CountingInputStream(new FileInputStream(file));
  BufferedReader reader = new BufferedReader(new InputStreamReader(stream, "utf-8"))
) {
 
  for(String line = reader.readLine(); line != null; line = reader.readLine()) {
    // traiter la ligne
    System.out.format("pourcentage : %f%%\n", 100.0*stream.getCount()/fileSize);
  }
 
}

Bien sûr c'est en supposant qu'il est vraiment impossible de savoir combien il y a de lignes dès le début.

[adiGuba]

Salut,

Bien sûr c'est en supposant qu'il est vraiment impossible de savoir combien il y a de lignes dès le début.

Je ne vois pas comment cela pourrait être possible sans lire le fichier deux fois...


Sinon pour éviter d'obtenir le 100% trop tôt on peut utiliser un Math.min() pour gruger et ne pas dépasser les 99% pendant le traitement :

Code :

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

1
2
3
4
5
  for(String line = reader.readLine(); line != null; line = reader.readLine()) {
    // traiter la ligne
    System.out.format("pourcentage : %f%%\n", Math.min(99.0, 100.0*stream.getCount()/fileSize));
  }
  System.out.format("pourcentage : 100%%\n");

Sinon une autre astuce que j'ai déjà vu, et que je trouve vraiment maligne, c'est de ne pas s'embêter avec tout cela et d'utiliser une fausse barre de progression basé sur le temps de traitement moyen...
Ou encore plus simple utiliser un ajaxloader.gif


a++

[thelvin]

Je ne vois pas comment cela pourrait être possible sans lire le fichier deux fois...

Pourtant il y a plein d'autres techniques communes :
- charger d'abord toutes les lignes en mémoire, et les traiter ensuite (défaut : on peut pas charger un fichier trop gros)
- la première ligne est un nombre qui indique combien il y a de lignes ensuite (défaut : il faut concevoir le fichier comme ça dès le début, et c'est une information redondante avec le vrai nombre de lignes. Il est possible de construire un fichier pour indiquer un mauvais nombre de lignes.)
- le système qui fournit le fichier a retenu le nombre de lignes dans ce fichier, et communique cette information en plus du fichier lui-même. Ça peut être considéré comme un cache des métadonnées qui ont déjà été calculées. (Défaut : comme au-dessus.)

[adiGuba]

Oui... mais dans le premier car tu traites deux fois le fichier quand même (et cela peut être gourmand en mémoire selon le fichier).
Pour le reste ca reste des traitements particuliers basés sur le traitement des fichiers...

Je parlais plutôt d'un point de vue plus global...


a++

[tchize_]

La question fondamentale c'est: est-ce que tu as un besoin particulier qui nécessite de s'emmerder à faire un barre précise plutot qu'une barre approximative?

Si c'est pour une progressbar, non seulement l'utilisateur ne verra pas l'approximation, mais en plus même si t'es précis, l'utilisateur aura l'impression que ça foire parce que ce que veux l'utilisateur, c'est pas une progression en terme de travail accompli / restant, mais en termes de temps passé / temps restant

[dumbl]

@tchize_ : Ta vision semble être la même que celle de Windows, envoie ton CV !!

[thelvin]

En même temps, après réflexion, je crois bien qu'il y a vraiment que mes partenaires commerciaux pour tenir à ce que, quand j'annonce un pourcentage de la tâche traitée, cela correspond exactement au nombre d'actions qu'ils constatent traitées à ce moment-là divisé par le nombre d'actions qu'ils savent qu'il y a à traiter dans le fichier.
En plus j'avais pensé à l'époque, pour leur faire plaisir, à remplacer "pourcentage effectué" par "lecture du fichier de travail... X% lus" (sous-entendu j'ai dit que le fichier a été lu à telle hauteur, pas quel pourcentage des actions ont été faites. De toute façon la lecture ne se continue qu'au fur et à mesure que les actions sont faites, donc la différence est minime, mais il y en a une non-mesurable.) Mais du coup ils voulaient pas que je reformule ma formulation malheureuse, ils voulaient que je leur fasse le calcul précis.

Ça les arrange bien pour faire des tests et vérifier qu'on les enfume pas je comprends, mais des nouveaux coûts de développement pour ça, ça me semble pas vraiment malin sur le fond.

[tchize_]

@dumbl tu pourrais élaborer ta relfexion? J'ai du mal à comprendre son sens....

[adiGuba]

Ça les arrange bien pour faire des tests et vérifier qu'on les enfume pas je comprends, mais des nouveaux coûts de développement pour ça, ça me semble pas vraiment malin sur le fond.

+1

Parfois le calcul du pourcentage est plus complexe à réaliser que le traitement lui même...


a++

[dumbl]

@tchize_ : Sur window on se retrouve souvent à 100% et elle reste planter pendant longtemps.

[thelvin]

Ailleurs aussi... Parce qu'en général le temps des finitions n'est pas compté.

[wax78]

Guava propose CountingInputStream qui peut te dire à tout moment combien d'octets tu as lus dans le fichier.
[/CODE]

Pourquoi utiliser ces libs et pourquoi ne pas simplement additionner le nbr de bytes contenue dans chaque ligne lue ?

[thelvin]

Pas faux. J'ai la manie de la précision absolue, et on ne peut pas savoir exactement combien il y avait d'octets dans une ligne. Mais c'est vrai que c'est pas pour la différence que ça fait...