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)
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?question=165
Et au passage, "Comment réaliser un benchmark"
http://faq.vb.free.fr/index.php?question=118
puis "Comment mesurer précisément le temps":
http://faq.vb.free.fr/index.php?question=176#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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
teddy
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" a écrit dans le message 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)
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.
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" <NO_SPAM_jean_marc_n2@yahoo.fr.invalid> a écrit dans le message
de news: 472dd3f9$0$29254$ba620e4c@news.skynet.be...
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)
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.
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" a écrit dans le message 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)
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.
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.
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.
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.
