[benchmark] - FSO et autres méthodes

Le
Jean-marc
Salut à tous,

Je renoue avec la tradition du "Benchmark Du Dimanche" :-)

On a récemment évoqué ici la problématique de la lecture
d'un fichier texte, avec FSO ou avec d'autres méthodes.

J'ai réalisé un petit benchmark pour comparer:
- La lecture ligne par ligne avec "Input Line"
- La lecture en bloc avec Get et Split
- La lecture utilisant FSO

Voici les résultats, pour des fichiers de différente taille (nombre de
lignes)

+-+-+-+--+
| 10000 | 50000 | 77000 | 100000 |
+--+-+-+-+--+
| Line Input | 131 | 648 | 995 | 1291 |
+--+-+-+-+--+
| Bloc (Get & Split) | 92 | 455 | 718 | 971 |
+--+-+-+-+--+
| FSO | 246 | 1225 | 1891 | 2455 |
+--+-+-+-+--+

Sans surprise, la lecture en bloc est la plus rapide, et
FSO de loin la plus mauvaise, les performances se
dégradant en plus avec la taille du fichier.

Les résultats sous forme graphique ici:
http://users.skynet.be/candide/jmn/benchreadfile/benchreadfile.html

On pourra donc lire ou relire en complément:

"Comment lire rapidement un fichier texte":
http://faq.vb.free.fr/index.php?question5

Et au passage, "Comment réaliser un benchmark"
http://faq.vb.free.fr/index.php?question8

puis "Comment mesurer précisément le temps":
http://faq.vb.free.fr/index.php?question6#p5

Pour conclure, un petit rappel, relié à la discussion
http://groups.google.fr/group/microsoft.public.fr.vb/browse_thread/thread/941fbe74680b3624/afe2889057dd35d0?hl=fr&lnk=raot#afe2889057dd35d0

Quand on mesure les performances d'un processus constitué de plusieurs
tâches s'exécuant en série (l'une après l'autre), il faut garder à l'esprit
que le temps total du processus est la somme des temps des 2 (ou n) des
tâches.

Or, si l'une des tâches demande un temps très supérieur aux autres, il est
évident que c'est le temps d'exécution de cette dernière qui est le facteur
limitant. Ainsi, pour la lecture d'un fichier de 77000 lignes suivi de
l'insertion de ces lignes dans une base de données, il est clair que c'est
l'insertion en base qui constitue le facteur (très) limitant; on a mesuré
environ 20 secondes pour faire l'insertion. Mais même la méthode la plus
médiocre (FSO) ne prend que 2 secondes pour la partie lecture du fichier,
soit moins de 10%.
Dans ce cas, peut importe finalement la méthode de lecture choisie : les
performances abominables de FSO sont "masquées" par le reste du process,
dont le temps d'exécution est très supérieur (d'au moins un ordre de
grandeur).

C'est ce que j'appelle le "mythe de l'oeuf sur le plat".
Pour faire un oeuf au plat, il faut:
1) Casser l'oeuf : de 1 à 3 secondes
2) Cuire l'oeuf : de 2 à 3 minutes.

Même le meilleur et le plus rapide casseur d'oeuf de la terre
devra attendre entre 2 et 3 minutes pour manger son oeuf. Il ne
sert à rien d'être performant sur cette partie du processus, le
temps d'attente est de toute façon conditionné par la cuisson.
Réciproque : même un casseur d'oeuf très lent et très médiocre,
qui mettrait 10 secondes à casser son oeuf n'influencera pas
significativement de façon négative le processus de préparation
de l'oeuf au plat. Sa médiocrité est "diluée" dans le temps de
cuisson, qui est plus ou moins un invariant.

Ouf!

Bon dimanche à tous :-)

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
teddy
Le #15388171
Bonjour,
Je suis d'accord que l'écriture dans la base de données est certainement la
tâche la + consommatrice de temps (et de loin...).
Pourtant, j'ai lu que la lecture en bloc n'est pas toujours une solution
optimale quant à l'utilisation de la mémoire.
Je n'ai pas encore testé Input Line mais je vais le faire dès que possible
pour voir si la différence est très significative.


"Jean-marc" de news: 472dd3f9$0$29254$
Salut à tous,

Je renoue avec la tradition du "Benchmark Du Dimanche" :-)

On a récemment évoqué ici la problématique de la lecture
d'un fichier texte, avec FSO ou avec d'autres méthodes.

J'ai réalisé un petit benchmark pour comparer:
- La lecture ligne par ligne avec "Input Line"
- La lecture en bloc avec Get et Split
- La lecture utilisant FSO

Voici les résultats, pour des fichiers de différente taille (nombre de
lignes)

+-------+-------+-------+--------+
| 10000 | 50000 | 77000 | 100000 |
+--------------------+-------+-------+-------+--------+
| Line Input | 131 | 648 | 995 | 1291 |
+--------------------+-------+-------+-------+--------+
| Bloc (Get & Split) | 92 | 455 | 718 | 971 |
+--------------------+-------+-------+-------+--------+
| FSO | 246 | 1225 | 1891 | 2455 |
+--------------------+-------+-------+-------+--------+

Sans surprise, la lecture en bloc est la plus rapide, et
FSO de loin la plus mauvaise, les performances se
dégradant en plus avec la taille du fichier.

Les résultats sous forme graphique ici:
http://users.skynet.be/candide/jmn/benchreadfile/benchreadfile.html

On pourra donc lire ou relire en complément:

"Comment lire rapidement un fichier texte":
http://faq.vb.free.fr/index.php?question5

Et au passage, "Comment réaliser un benchmark"
http://faq.vb.free.fr/index.php?question8

puis "Comment mesurer précisément le temps":
http://faq.vb.free.fr/index.php?question6#p5

Pour conclure, un petit rappel, relié à la discussion
http://groups.google.fr/group/microsoft.public.fr.vb/browse_thread/thread/941fbe74680b3624/afe2889057dd35d0?hl=fr&lnk=raot#afe2889057dd35d0

Quand on mesure les performances d'un processus constitué de plusieurs
tâches s'exécuant en série (l'une après l'autre), il faut garder à
l'esprit que le temps total du processus est la somme des temps des 2 (ou
n) des tâches.

Or, si l'une des tâches demande un temps très supérieur aux autres, il est
évident que c'est le temps d'exécution de cette dernière qui est le
facteur limitant. Ainsi, pour la lecture d'un fichier de 77000 lignes
suivi de l'insertion de ces lignes dans une base de données, il est clair
que c'est l'insertion en base qui constitue le facteur (très) limitant; on
a mesuré environ 20 secondes pour faire l'insertion. Mais même la méthode
la plus médiocre (FSO) ne prend que 2 secondes pour la partie lecture du
fichier, soit moins de 10%.
Dans ce cas, peut importe finalement la méthode de lecture choisie : les
performances abominables de FSO sont "masquées" par le reste du process,
dont le temps d'exécution est très supérieur (d'au moins un ordre de
grandeur).

C'est ce que j'appelle le "mythe de l'oeuf sur le plat".
Pour faire un oeuf au plat, il faut:
1) Casser l'oeuf : de 1 à 3 secondes
2) Cuire l'oeuf : de 2 à 3 minutes.

Même le meilleur et le plus rapide casseur d'oeuf de la terre
devra attendre entre 2 et 3 minutes pour manger son oeuf. Il ne
sert à rien d'être performant sur cette partie du processus, le
temps d'attente est de toute façon conditionné par la cuisson.
Réciproque : même un casseur d'oeuf très lent et très médiocre,
qui mettrait 10 secondes à casser son oeuf n'influencera pas
significativement de façon négative le processus de préparation
de l'oeuf au plat. Sa médiocrité est "diluée" dans le temps de
cuisson, qui est plus ou moins un invariant.

Ouf!

Bon dimanche à tous :-)

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;




























Jean-marc
Le #15388101
teddy wrote:
Bonjour,



Hello,

Je suis d'accord que l'écriture dans la base de données est
certainement la tâche la + consommatrice de temps (et de loin...).
Pourtant, j'ai lu que la lecture en bloc n'est pas toujours une
solution optimale quant à l'utilisation de la mémoire.



C'est une évidence : la lecture en bloc nécessite d'allouer un
buffer en mémoire de la même taille que le fichier.

La lecture ligne par ligne ne consomme jamais plus de mémoire
que la taille d'une ligne.

MAIS, car il y un MAIS, qui s'en soucie?

Un gros fichier texte, ça fait en général qq centaines de MB, et ça
c'est accessible à n'importe quel PC fabriqué après 2002 ou 2003.
La durée de vie d'un PC (3 à 4 ans) étant ce qu'elle est, pas de gros
soucis.
Si on a des traitements réguliers à faire sur des fichiers plus gros
(plusieurs Giga), on a en général recours à une machine faite pour
(c'est à dire équipée de 2 ou 4 GB de RAM, ce qui btw est le standard
pour les machines actuelles).

Qui plus est, on peut moyennant un peu de travail faire une lecture
bloc avec des blocs de taille arbitraire. L'overhead entrainé
par la nécessité de gérer les overlaps et tout ça n'est pas
bien grand.

Je n'ai pas encore testé Input Line mais je vais le faire dès que
possible pour voir si la différence est très significative.



Elle l'est, mais ca ne serait pas visible dans ton programme
d'insertion en base: cf le mythe de l'oeuf sur le plat :-)

Ceci dit, pour des fichiers de moins de 300 ou 400.000 lignes,
ce n'est pas vraiement la peine de s'exciter à trouver des
méthodes révolutionnaires, le cout de traitement des lignes
excédant en général de beaucoup le temps de lecture.

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Publicité
Poster une réponse
Anonyme