Je dois remplir un flexgrid à partir de données présentes dans un fichier
texte avec séparateur.
Le problème, c'est que le fichier à charger peut être assez gros (maximum
10Mo) et le chargement prend un temps fou : 12s pour 6 Mo
Pour remplir le tableau j'utilise cette fonction qui marche très bien mais
qui rame quand même pas mal :
http://groups.google.fr/groups?hl=fr&lr=&rls=GGLD,GGLD:2004-51,GGLD:fr&selm=O8AEg53fCHA.1860%40tkmsftngp09&rnum=7
J'ai fait des essais toujours avec la même fonction à peine modifiée avec un
autre contrôle (vbalgrid de VBAccelerator) et les temps de chargement sont
encore pire ! Comme quoi le temps de chargement ne dépend pas que de notre
code.
Pourtant, je vois des applications qui chargent 2000 lignes dans ce type de
contrôle en un clin d'oeil. Mais comment font-il ? ;-) Je doute que ce soit
en VB où alors je ne sais pas m'y prendre et il existe une astuce ou une
autre façon de faire ?
Jean-Marc wrote: > Voici le code final avec une petite modification. > > Les performance sont finalement de 0,58 contre 9 > initialement.
J'ai pu tester et je confirme une très nette amélioration du temps de traitement. Ici je suis un peu au dessus (proche des deux secondes) car je n'ai pas une machine ultra-puissante mais je dirais que ce n'est pas plus mal car ça me permet de détecter de telles anomalies au niveau du temps d'exécution. Donc oui, y'a pas photo, c'est le jour et la nuit entre le
code
initial et celui-ci !
Encore merci et bonne journée
C'était avec plaisr :-)
Ceci illustre bien plusieurs choses, que l'on ne dit peut être pas assez souvent sur ce ng:
Il ne faut pas essayer d'optimiser pour le plaisir ou en tatonnant, mais au contraire être sur d'avoir localisé la cause du problème avant tout essai d'optimisation. Le langage VB en lui même est plutôt assez performant en terme de vitesse. Il ne faut pas chercher à "ruser" avec le langage mais tout au contraire essayer d'appliquer des principes simples d'algorithmique: faire le maximum en dehors des boucles, faire le maximum de prétraitements. Enfin, et c'est le plus important, faire des tests et encore des tests pour avoir une vue concrète, basée sur des faits, des temps de traitements des différentes parties du code que l'on essaie d'améliorer. Je vois trop de programmeurs pondre du code illisible sous prétexte d'optimisations alors qu'une bonne analyse doublée de connaissances approfondies en algorithmique permettent de régler les choses dans 99,9% des cas. Quand l'analyse a montré que les performances ne peuvent plus être améliorées, de par la nature même du langage (ex: faiblesse du VB pour le traitement des chaînes de caractères), alors et alors seulement, il peut être temps de se tourner vers d'autres solutions, comme l'écriture des parties critiques dans un langage plus rapide (C).
Bonne journée aussi.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"F. David" <franck.dh@alussinan.org> a écrit dans le message de
news:eAxkTvHLFHA.244@TK2MSFTNGP12.phx.gbl...
Jean-Marc wrote:
> Voici le code final avec une petite modification.
>
> Les performance sont finalement de 0,58 contre 9
> initialement.
J'ai pu tester et je confirme une très nette amélioration du temps de
traitement. Ici je suis un peu au dessus (proche des deux secondes) car je
n'ai pas une machine ultra-puissante mais je dirais que ce n'est pas plus
mal car ça me permet de détecter de telles anomalies au niveau du temps
d'exécution. Donc oui, y'a pas photo, c'est le jour et la nuit entre le
code
initial et celui-ci !
Encore merci et bonne journée
C'était avec plaisr :-)
Ceci illustre bien plusieurs choses, que l'on ne dit peut être pas
assez souvent sur ce ng:
Il ne faut pas essayer d'optimiser pour le plaisir ou en tatonnant,
mais au contraire être sur d'avoir localisé la cause du problème avant
tout essai d'optimisation. Le langage VB en lui même est plutôt assez
performant en terme de vitesse. Il ne faut pas chercher à "ruser" avec
le langage mais tout au contraire essayer d'appliquer des principes
simples d'algorithmique: faire le maximum en dehors des boucles, faire
le maximum de prétraitements. Enfin, et c'est le plus important, faire
des tests et encore des tests pour avoir une vue concrète, basée sur
des faits, des temps de traitements des différentes parties du code que
l'on essaie d'améliorer. Je vois trop de programmeurs pondre du code
illisible sous prétexte d'optimisations alors qu'une bonne analyse
doublée de connaissances approfondies en algorithmique permettent de
régler les choses dans 99,9% des cas. Quand l'analyse a montré que les
performances ne peuvent plus être améliorées, de par la nature même du
langage (ex: faiblesse du VB pour le traitement des chaînes de
caractères), alors et alors seulement, il peut être temps de se tourner
vers d'autres solutions, comme l'écriture des parties critiques dans un
langage plus rapide (C).
Bonne journée aussi.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Jean-Marc wrote: > Voici le code final avec une petite modification. > > Les performance sont finalement de 0,58 contre 9 > initialement.
J'ai pu tester et je confirme une très nette amélioration du temps de traitement. Ici je suis un peu au dessus (proche des deux secondes) car je n'ai pas une machine ultra-puissante mais je dirais que ce n'est pas plus mal car ça me permet de détecter de telles anomalies au niveau du temps d'exécution. Donc oui, y'a pas photo, c'est le jour et la nuit entre le
code
initial et celui-ci !
Encore merci et bonne journée
C'était avec plaisr :-)
Ceci illustre bien plusieurs choses, que l'on ne dit peut être pas assez souvent sur ce ng:
Il ne faut pas essayer d'optimiser pour le plaisir ou en tatonnant, mais au contraire être sur d'avoir localisé la cause du problème avant tout essai d'optimisation. Le langage VB en lui même est plutôt assez performant en terme de vitesse. Il ne faut pas chercher à "ruser" avec le langage mais tout au contraire essayer d'appliquer des principes simples d'algorithmique: faire le maximum en dehors des boucles, faire le maximum de prétraitements. Enfin, et c'est le plus important, faire des tests et encore des tests pour avoir une vue concrète, basée sur des faits, des temps de traitements des différentes parties du code que l'on essaie d'améliorer. Je vois trop de programmeurs pondre du code illisible sous prétexte d'optimisations alors qu'une bonne analyse doublée de connaissances approfondies en algorithmique permettent de régler les choses dans 99,9% des cas. Quand l'analyse a montré que les performances ne peuvent plus être améliorées, de par la nature même du langage (ex: faiblesse du VB pour le traitement des chaînes de caractères), alors et alors seulement, il peut être temps de se tourner vers d'autres solutions, comme l'écriture des parties critiques dans un langage plus rapide (C).
Bonne journée aussi.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
LE TROLL
Tu fais de la pub pour l'ennemi "C" :o) -----
"Jean-Marc" a écrit dans le message de news: 423c1aed$0$14973$
"F. David" a écrit dans le message de news:
Jean-Marc wrote: > Voici le code final avec une petite modification. > > Les performance sont finalement de 0,58 contre 9 > initialement.
J'ai pu tester et je confirme une très nette amélioration du temps de traitement. Ici je suis un peu au dessus (proche des deux secondes) car je n'ai pas une machine ultra-puissante mais je dirais que ce n'est pas plus mal car ça me permet de détecter de telles anomalies au niveau du temps d'exécution. Donc oui, y'a pas photo, c'est le jour et la nuit entre le
code
initial et celui-ci !
Encore merci et bonne journée
C'était avec plaisr :-)
Ceci illustre bien plusieurs choses, que l'on ne dit peut être pas assez souvent sur ce ng:
Il ne faut pas essayer d'optimiser pour le plaisir ou en tatonnant, mais au contraire être sur d'avoir localisé la cause du problème avant tout essai d'optimisation. Le langage VB en lui même est plutôt assez performant en terme de vitesse. Il ne faut pas chercher à "ruser" avec le langage mais tout au contraire essayer d'appliquer des principes simples d'algorithmique: faire le maximum en dehors des boucles, faire le maximum de prétraitements. Enfin, et c'est le plus important, faire des tests et encore des tests pour avoir une vue concrète, basée sur des faits, des temps de traitements des différentes parties du code que l'on essaie d'améliorer. Je vois trop de programmeurs pondre du code illisible sous prétexte d'optimisations alors qu'une bonne analyse doublée de connaissances approfondies en algorithmique permettent de régler les choses dans 99,9% des cas. Quand l'analyse a montré que les performances ne peuvent plus être améliorées, de par la nature même du langage (ex: faiblesse du VB pour le traitement des chaînes de caractères), alors et alors seulement, il peut être temps de se tourner vers d'autres solutions, comme l'écriture des parties critiques dans un langage plus rapide (C).
Bonne journée aussi.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Tu fais de la pub pour l'ennemi "C" :o)
-----
"Jean-Marc" <webmaster@planetejm.atspace.com> a écrit dans
le message de news:
423c1aed$0$14973$ba620e4c@news.skynet.be...
"F. David" <franck.dh@alussinan.org> a écrit dans le
message de
news:eAxkTvHLFHA.244@TK2MSFTNGP12.phx.gbl...
Jean-Marc wrote:
> Voici le code final avec une petite modification.
>
> Les performance sont finalement de 0,58 contre 9
> initialement.
J'ai pu tester et je confirme une très nette amélioration
du temps de
traitement. Ici je suis un peu au dessus (proche des deux
secondes) car je
n'ai pas une machine ultra-puissante mais je dirais que
ce n'est pas plus
mal car ça me permet de détecter de telles anomalies au
niveau du temps
d'exécution. Donc oui, y'a pas photo, c'est le jour et la
nuit entre le
code
initial et celui-ci !
Encore merci et bonne journée
C'était avec plaisr :-)
Ceci illustre bien plusieurs choses, que l'on ne dit
peut être pas
assez souvent sur ce ng:
Il ne faut pas essayer d'optimiser pour le plaisir ou
en tatonnant,
mais au contraire être sur d'avoir localisé la cause du
problème avant
tout essai d'optimisation. Le langage VB en lui même
est plutôt assez
performant en terme de vitesse. Il ne faut pas chercher
à "ruser" avec
le langage mais tout au contraire essayer d'appliquer
des principes
simples d'algorithmique: faire le maximum en dehors des
boucles, faire
le maximum de prétraitements. Enfin, et c'est le plus
important, faire
des tests et encore des tests pour avoir une vue
concrète, basée sur
des faits, des temps de traitements des différentes
parties du code que
l'on essaie d'améliorer. Je vois trop de programmeurs
pondre du code
illisible sous prétexte d'optimisations alors qu'une
bonne analyse
doublée de connaissances approfondies en algorithmique
permettent de
régler les choses dans 99,9% des cas. Quand l'analyse a
montré que les
performances ne peuvent plus être améliorées, de par la
nature même du
langage (ex: faiblesse du VB pour le traitement
des chaînes de
caractères), alors et alors seulement, il peut être temps
de se tourner
vers d'autres solutions, comme l'écriture des parties
critiques dans un
langage plus rapide (C).
Bonne journée aussi.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Jean-Marc" a écrit dans le message de news: 423c1aed$0$14973$
"F. David" a écrit dans le message de news:
Jean-Marc wrote: > Voici le code final avec une petite modification. > > Les performance sont finalement de 0,58 contre 9 > initialement.
J'ai pu tester et je confirme une très nette amélioration du temps de traitement. Ici je suis un peu au dessus (proche des deux secondes) car je n'ai pas une machine ultra-puissante mais je dirais que ce n'est pas plus mal car ça me permet de détecter de telles anomalies au niveau du temps d'exécution. Donc oui, y'a pas photo, c'est le jour et la nuit entre le
code
initial et celui-ci !
Encore merci et bonne journée
C'était avec plaisr :-)
Ceci illustre bien plusieurs choses, que l'on ne dit peut être pas assez souvent sur ce ng:
Il ne faut pas essayer d'optimiser pour le plaisir ou en tatonnant, mais au contraire être sur d'avoir localisé la cause du problème avant tout essai d'optimisation. Le langage VB en lui même est plutôt assez performant en terme de vitesse. Il ne faut pas chercher à "ruser" avec le langage mais tout au contraire essayer d'appliquer des principes simples d'algorithmique: faire le maximum en dehors des boucles, faire le maximum de prétraitements. Enfin, et c'est le plus important, faire des tests et encore des tests pour avoir une vue concrète, basée sur des faits, des temps de traitements des différentes parties du code que l'on essaie d'améliorer. Je vois trop de programmeurs pondre du code illisible sous prétexte d'optimisations alors qu'une bonne analyse doublée de connaissances approfondies en algorithmique permettent de régler les choses dans 99,9% des cas. Quand l'analyse a montré que les performances ne peuvent plus être améliorées, de par la nature même du langage (ex: faiblesse du VB pour le traitement des chaînes de caractères), alors et alors seulement, il peut être temps de se tourner vers d'autres solutions, comme l'écriture des parties critiques dans un langage plus rapide (C).
Bonne journée aussi.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
