simple question : je me demande si le vba sous excel est=20
un langage compil=E9 ou intrepr=E9t=E9 ?
en fait, j'ai un prog qui tourne sous excel avec des=20
donn=E9es dans les feuilles.
Malheureusement, il prend un tps fous genre 25 min parce=20
que jai des boucles qui le font mouliner tres longtemps.
Je me demandais donc si en mettant mon prog en c++ ou java=20
ou autre, mon prog tournerai plus vite.
D'ou ma question...
Merci de m'apporter de l aide et si vous avez une solution=20
pour que mon prog puisse aller plus vite ce serait genial.
ok pour le application.match, je viens de le lire sur le lien que tu m'as donné. Je vais essayer de l'utiliser au max. Pour les tableaux, je vais le faire et voir ce que ca donne. Mais a priori ca devrait accelerer le truc parce qu'en fait, il y a bien trop de lecture et d'ecriture dans les feuilles pour des choses qui ne sont que temporaires. En fait la personne qui a fait ce code stocke la plupart de ses calculs temporaires dans des cellules ....perte de tps ( meme si c'est interessant pour controler la justesse des calculs)
apres ca, je verrai... soit ce sera acceptable soit effectivement je rappliquerai :-)
merci et a +
pierre
-----Message d'origine----- Pierre,
Si tu fais des recherches en vérifiant le contenu des cellules UNE à UNE (par
des boucle), déjà là, il y a matière à optimiser (Application.Match() et
autres).
C'est vrai que ça va un peu plus vite en consultant des tableaux plutôt que des
plages mais quand on a 25 minutes de traitement, le problème si situe plus au
niveau du nombre de comparaisons effectuées (que celles- ci aient lieu sur des
plages ou des tableaux en mémoire importe moins). Il faut quand même pas oublier
que les cellules sont mises en mémoire vive également (les accès sont
ultra-rapides là aussi).
En tout cas, rapplique ici si tu veux de l'aide. :-)
Salutations,
Daniel M.
"pierref" wrote in message
news:065001c3bf2d$cc6ee8c0$ Merci beaucoup pour tout ces conseils !
Je vous remercie de proposer de m'aider. Dans un premier temps, je vais qd meme essayer d'optimiser mon code du coté acces aux feuilles excel. Je vais creer des tableaux dans mes methodes aux lieux d'utiliser ceux des feuilles (le code d'origine n'est pas de moi...je l'ai optimisé mais il se sert encore bcp trop des feuilles)
Si ca ne tourne tjs pas a une vitesse correcte, je vous recontacterai surement.
En tout cas merci et je vais egalement regarder l'api-c qui pourra m'etre utile.
++
pierre
-----Message d'origine----- Salut Pierre,
Mais 2 questions 1) vais-je vraiment gagner du temps ? 2) quelle langage utilisé ?(je pense c++ ou java mais lequelle tournera le mieux ?)
Oui, en choisissant un langage compilé, tu risques de gagner du temps. Mais dans
la même foulée que Denis, je réitère mon offre (à laquelle plusieurs se
joindront ici, j'en suis convaincu).
Quant à C++ ou Java, pour produire le code le plus rapide (ce qui est ton
critère principal), il n'y a pas de doutes que C++ va gagner. Et, dans la même
veine, pourquoi pas C (produisant une XLL). C'est une vieille interface mais
elle est directe avec Excel et les performances sont là (http://longre.free.fr/pages/prog/api-c.htm)!
Salutations,
Daniel M.
.
.
ok
pour le application.match, je viens de le lire sur le lien
que tu m'as donné. Je vais essayer de l'utiliser au max.
Pour les tableaux, je vais le faire et voir ce que ca
donne. Mais a priori ca devrait accelerer le truc parce
qu'en fait, il y a bien trop de lecture et d'ecriture dans
les feuilles pour des choses qui ne sont que temporaires.
En fait la personne qui a fait ce code stocke la plupart
de ses calculs temporaires dans des cellules ....perte de
tps ( meme si c'est interessant pour controler la justesse
des calculs)
apres ca, je verrai... soit ce sera acceptable soit
effectivement je rappliquerai :-)
merci et a +
pierre
-----Message d'origine-----
Pierre,
Si tu fais des recherches en vérifiant le contenu des
cellules UNE à UNE (par
des boucle), déjà là, il y a matière à optimiser
(Application.Match() et
autres).
C'est vrai que ça va un peu plus vite en consultant des
tableaux plutôt que des
plages mais quand on a 25 minutes de traitement, le
problème si situe plus au
niveau du nombre de comparaisons effectuées (que celles-
ci aient lieu sur des
plages ou des tableaux en mémoire importe moins). Il faut
quand même pas oublier
que les cellules sont mises en mémoire vive également
(les accès sont
ultra-rapides là aussi).
En tout cas, rapplique ici si tu veux de l'aide. :-)
Salutations,
Daniel M.
"pierref" <anonymous@discussions.microsoft.com> wrote in
message
news:065001c3bf2d$cc6ee8c0$a001280a@phx.gbl...
Merci beaucoup pour tout ces conseils !
Je vous remercie de proposer de m'aider.
Dans un premier temps, je vais qd meme essayer d'optimiser
mon code du coté acces aux feuilles excel. Je vais creer
des tableaux dans mes methodes aux lieux d'utiliser ceux
des feuilles (le code d'origine n'est pas de moi...je l'ai
optimisé mais il se sert encore bcp trop des feuilles)
Si ca ne tourne tjs pas a une vitesse correcte, je vous
recontacterai surement.
En tout cas merci et je vais egalement regarder l'api-c
qui pourra m'etre utile.
++
pierre
-----Message d'origine-----
Salut Pierre,
Mais 2 questions
1) vais-je vraiment gagner du temps ?
2) quelle langage utilisé ?(je pense c++ ou java mais
lequelle tournera le mieux ?)
Oui, en choisissant un langage compilé, tu risques de
gagner du temps. Mais dans
la même foulée que Denis, je réitère mon offre (à
laquelle plusieurs se
joindront ici, j'en suis convaincu).
Quant à C++ ou Java, pour produire le code le plus rapide
(ce qui est ton
critère principal), il n'y a pas de doutes que C++ va
gagner. Et, dans la même
veine, pourquoi pas C (produisant une XLL). C'est une
vieille interface mais
elle est directe avec Excel et les performances sont là
(http://longre.free.fr/pages/prog/api-c.htm)!
ok pour le application.match, je viens de le lire sur le lien que tu m'as donné. Je vais essayer de l'utiliser au max. Pour les tableaux, je vais le faire et voir ce que ca donne. Mais a priori ca devrait accelerer le truc parce qu'en fait, il y a bien trop de lecture et d'ecriture dans les feuilles pour des choses qui ne sont que temporaires. En fait la personne qui a fait ce code stocke la plupart de ses calculs temporaires dans des cellules ....perte de tps ( meme si c'est interessant pour controler la justesse des calculs)
apres ca, je verrai... soit ce sera acceptable soit effectivement je rappliquerai :-)
merci et a +
pierre
-----Message d'origine----- Pierre,
Si tu fais des recherches en vérifiant le contenu des cellules UNE à UNE (par
des boucle), déjà là, il y a matière à optimiser (Application.Match() et
autres).
C'est vrai que ça va un peu plus vite en consultant des tableaux plutôt que des
plages mais quand on a 25 minutes de traitement, le problème si situe plus au
niveau du nombre de comparaisons effectuées (que celles- ci aient lieu sur des
plages ou des tableaux en mémoire importe moins). Il faut quand même pas oublier
que les cellules sont mises en mémoire vive également (les accès sont
ultra-rapides là aussi).
En tout cas, rapplique ici si tu veux de l'aide. :-)
Salutations,
Daniel M.
"pierref" wrote in message
news:065001c3bf2d$cc6ee8c0$ Merci beaucoup pour tout ces conseils !
Je vous remercie de proposer de m'aider. Dans un premier temps, je vais qd meme essayer d'optimiser mon code du coté acces aux feuilles excel. Je vais creer des tableaux dans mes methodes aux lieux d'utiliser ceux des feuilles (le code d'origine n'est pas de moi...je l'ai optimisé mais il se sert encore bcp trop des feuilles)
Si ca ne tourne tjs pas a une vitesse correcte, je vous recontacterai surement.
En tout cas merci et je vais egalement regarder l'api-c qui pourra m'etre utile.
++
pierre
-----Message d'origine----- Salut Pierre,
Mais 2 questions 1) vais-je vraiment gagner du temps ? 2) quelle langage utilisé ?(je pense c++ ou java mais lequelle tournera le mieux ?)
Oui, en choisissant un langage compilé, tu risques de gagner du temps. Mais dans
la même foulée que Denis, je réitère mon offre (à laquelle plusieurs se
joindront ici, j'en suis convaincu).
Quant à C++ ou Java, pour produire le code le plus rapide (ce qui est ton
critère principal), il n'y a pas de doutes que C++ va gagner. Et, dans la même
veine, pourquoi pas C (produisant une XLL). C'est une vieille interface mais
elle est directe avec Excel et les performances sont là (http://longre.free.fr/pages/prog/api-c.htm)!