j'ai deux fichiers texte comportant 259920 lignes
sur chaque ligne se trouve un nombre avec deux décimales(le séparateur
est un point)
je voudrais trouver une solution rapide pour avoir un résultat
d'opération entre chaque ligne des fichiers
ex:
result1 = sqr(ligne1fichier1^2 + ligne1fichier2^2)
etc
j'ai essayé en mettant les deux fichiers en mémoire puis opération
entre chaque ligne, cela prend un temps mais un
temps..............enfin bref trop de temps
une solution plus rapide est envisageable ?
JP
--
Adresse mail : john-pet@wanadoo.fr
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Un grand merci pour ce morceau de code, du grand art j'ai juste changé le vbCrLf par vbCr car les fichiers sont au format unix,
Re,
si tu as fréquemment des fichiers au format Unix à convertir en format Dos et si tu souhaites l'automatiser, j'avais écrit une petite fonction pour faire ça, disponible dans la FAQ:
Un grand merci pour ce morceau de code, du grand art
j'ai juste changé le vbCrLf par vbCr car les fichiers sont au format
unix,
Re,
si tu as fréquemment des fichiers au format Unix à convertir
en format Dos et si tu souhaites l'automatiser, j'avais écrit
une petite fonction pour faire ça, disponible dans la FAQ:
Un grand merci pour ce morceau de code, du grand art j'ai juste changé le vbCrLf par vbCr car les fichiers sont au format unix,
Re,
si tu as fréquemment des fichiers au format Unix à convertir en format Dos et si tu souhaites l'automatiser, j'avais écrit une petite fonction pour faire ça, disponible dans la FAQ:
Voilà j'ai modifié avec un calcul supplémentaire pour determiner la direction du vent (un peu plus complexe que la force) soit 519840 calculs en tout, j'ai un temps qui oscille entre 3 et 15 s suivant l'ordi c'est super comme résulat, un grand merci
à bientôt
JP
-- Adresse mail : Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Voilà j'ai modifié avec un calcul supplémentaire pour determiner la
direction du vent (un peu plus complexe que la force) soit 519840
calculs en tout, j'ai un temps qui oscille entre 3 et 15 s suivant
l'ordi
c'est super comme résulat, un grand merci
à bientôt
JP
--
Adresse mail : john-pet@wanadoo.fr
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Voilà j'ai modifié avec un calcul supplémentaire pour determiner la direction du vent (un peu plus complexe que la force) soit 519840 calculs en tout, j'ai un temps qui oscille entre 3 et 15 s suivant l'ordi c'est super comme résulat, un grand merci
à bientôt
JP
-- Adresse mail : Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Jean-marc
John-Pet wrote:
Voilà j'ai modifié avec un calcul supplémentaire pour determiner la direction du vent (un peu plus complexe que la force) soit 519840 calculs en tout, j'ai un temps qui oscille entre 3 et 15 s suivant l'ordi c'est super comme résulat, un grand merci
Merci à toi pour le retour!
Quelques précisions:
Tu peux gagner encore environ 10% en vitesse en diminuant la taille du bufferChunck, en ajoutant ceci dans ProcessFiles juste avant le Do While :
Moi je passe d'un temps de process de 2,75 à 2,42 (soit 12% de mieux), un gain de 300 millisecondes.
Si il le fallait, on pourrait encore gagner la dessus environ 30%, pour arriver à quelque chose de l'ordre de 1,8 secondes environ.
L'idée est de faire un SmoothFileWriter, sur le même genre de principe que pour le reader, car la fonction passe *40%* de son temps total à écrire le fichier résultat. C'est donc la qu'il faut agir.
Pour info, le calcul proprement dit (2 mises au carré et une racine carrée) ne prend que *10%* du temps de la fonction, et je suis sur que les autres calculs ne consomment pas grand chose: les CPU modernes confient tout ça au processeur mathématique.
Voilà j'ai modifié avec un calcul supplémentaire pour determiner la
direction du vent (un peu plus complexe que la force) soit 519840
calculs en tout, j'ai un temps qui oscille entre 3 et 15 s suivant
l'ordi
c'est super comme résulat, un grand merci
Merci à toi pour le retour!
Quelques précisions:
Tu peux gagner encore environ 10% en vitesse en diminuant
la taille du bufferChunck, en ajoutant ceci dans ProcessFiles
juste avant le Do While :
Moi je passe d'un temps de process de 2,75 à 2,42 (soit 12% de mieux),
un gain de 300 millisecondes.
Si il le fallait, on pourrait encore gagner la dessus environ 30%, pour
arriver à quelque chose de l'ordre de 1,8 secondes environ.
L'idée est de faire un SmoothFileWriter, sur le même genre de principe
que pour le reader, car la fonction passe *40%* de son temps total à écrire
le fichier résultat. C'est donc la qu'il faut agir.
Pour info, le calcul proprement dit (2 mises au carré et une
racine carrée) ne prend que *10%* du temps de la fonction, et je suis sur
que les autres calculs ne consomment pas grand chose: les CPU modernes
confient tout ça au processeur mathématique.
Voilà j'ai modifié avec un calcul supplémentaire pour determiner la direction du vent (un peu plus complexe que la force) soit 519840 calculs en tout, j'ai un temps qui oscille entre 3 et 15 s suivant l'ordi c'est super comme résulat, un grand merci
Merci à toi pour le retour!
Quelques précisions:
Tu peux gagner encore environ 10% en vitesse en diminuant la taille du bufferChunck, en ajoutant ceci dans ProcessFiles juste avant le Do While :
Moi je passe d'un temps de process de 2,75 à 2,42 (soit 12% de mieux), un gain de 300 millisecondes.
Si il le fallait, on pourrait encore gagner la dessus environ 30%, pour arriver à quelque chose de l'ordre de 1,8 secondes environ.
L'idée est de faire un SmoothFileWriter, sur le même genre de principe que pour le reader, car la fonction passe *40%* de son temps total à écrire le fichier résultat. C'est donc la qu'il faut agir.
Pour info, le calcul proprement dit (2 mises au carré et une racine carrée) ne prend que *10%* du temps de la fonction, et je suis sur que les autres calculs ne consomment pas grand chose: les CPU modernes confient tout ça au processeur mathématique.
comme je n'aime pas faire les choses à moitié ni rester sur un doute, j'ai fait la modif en ajoutant une écriture fichier plus efficace, basée sur la méthode de concatnéation rapide présentée dans la FAQ: http://faq.vb.free.fr/index.php?question3
J'ai donc modifié légèrement le code déjà fourni en ajoutant ce que je proposais, et en ajoutant au passage le Round() pour sortir les résultats à 2 décimales, comme tu le fais.
Résultat: le process se fait maintenant en 1,78 secondes au lieu des 2,72 initiales (avec le round en plus).
On a donc bien le gain que j'espérais, le nouveau code est environ 60% plus rapide que la version initiale :-)
Tout est la: http://users.skynet.be/candide/smooth/
Preuve, s'il en était encore besoin, qu'un bon programme en VB peut atteindre des niveaux de performances tout à fait remarquables.
Preuve également que ce n'est jamais (ou presque) le langage en soi qui fait qu'un programme est performant, mais bien les algorithmes et méthodes utilisés.
Pour la petite histoire, j'ai écrit le même programme en C: les résultats sont (pour moi) sans surprise: je ne parviens pas à mesurer une différence de temps d'exécution significative entre les 2 versions, VB et C (moins de 1% d'écart, et encore).
comme je n'aime pas faire les choses à moitié ni
rester sur un doute, j'ai fait la modif en
ajoutant une écriture fichier plus efficace,
basée sur la méthode de concatnéation rapide présentée
dans la FAQ:
http://faq.vb.free.fr/index.php?question3
J'ai donc modifié légèrement le code déjà
fourni en ajoutant ce que je proposais, et en ajoutant
au passage le Round() pour sortir les résultats à 2
décimales, comme tu le fais.
Résultat: le process se fait maintenant en 1,78 secondes
au lieu des 2,72 initiales (avec le round en plus).
On a donc bien le gain que j'espérais, le nouveau code est
environ 60% plus rapide que la version initiale :-)
Tout est la:
http://users.skynet.be/candide/smooth/
Preuve, s'il en était encore besoin, qu'un bon programme en VB
peut atteindre des niveaux de performances tout à fait
remarquables.
Preuve également que ce n'est jamais (ou presque) le langage en soi
qui fait qu'un programme est performant, mais bien les algorithmes
et méthodes utilisés.
Pour la petite histoire, j'ai écrit le même programme en C: les
résultats sont (pour moi) sans surprise: je ne parviens pas à
mesurer une différence de temps d'exécution significative entre
les 2 versions, VB et C (moins de 1% d'écart, et encore).
comme je n'aime pas faire les choses à moitié ni rester sur un doute, j'ai fait la modif en ajoutant une écriture fichier plus efficace, basée sur la méthode de concatnéation rapide présentée dans la FAQ: http://faq.vb.free.fr/index.php?question3
J'ai donc modifié légèrement le code déjà fourni en ajoutant ce que je proposais, et en ajoutant au passage le Round() pour sortir les résultats à 2 décimales, comme tu le fais.
Résultat: le process se fait maintenant en 1,78 secondes au lieu des 2,72 initiales (avec le round en plus).
On a donc bien le gain que j'espérais, le nouveau code est environ 60% plus rapide que la version initiale :-)
Tout est la: http://users.skynet.be/candide/smooth/
Preuve, s'il en était encore besoin, qu'un bon programme en VB peut atteindre des niveaux de performances tout à fait remarquables.
Preuve également que ce n'est jamais (ou presque) le langage en soi qui fait qu'un programme est performant, mais bien les algorithmes et méthodes utilisés.
Pour la petite histoire, j'ai écrit le même programme en C: les résultats sont (pour moi) sans surprise: je ne parviens pas à mesurer une différence de temps d'exécution significative entre les 2 versions, VB et C (moins de 1% d'écart, et encore).