Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Merci pour cet échange "technique" pour le moins, même si, du fait de mon niveau, j'aurai du mal à appliquer tous ces conseils (je vais aller lire les FAQ citées de suite.) En tout cas ça décrasse les méninges.. Dans la même veine , contrairement au TROLL, j'utilise autant que faire ce peut les procédures et les fonctions. Jusqu'à quel point faire cela est-il utile ? je m'explique : j'utilise cela dès que je pense qu'une action sera demandée plusieurs fois, aussi bien dans la feuille en cours que dans d'autres. Mais aussi, lorsque dans une fonction assez "complexe" (pour moi bien sûr), je dois rajouter un traitement lui aussi compliqué. Alors je m'arrange pour mettre ceci dans une procédure afin de gagner en "lisibilité". Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à appeler une procédure externe ? je ne suis pas au point de réécrire tous les algorythmes, même si cela me prend, mais je voudrai ne pas trop perdre en efficacité..
Merci
Driss
"jean-marc" a écrit dans le message de news: 48bf9ee9$0$2870$
"Sebastien" wrote in message news:
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est juste des cas ou il sera 'naturel' de l'employer. Mais tu as raison, il n'est jamais plus perfomant qu'autre chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :) Je manquerais pas de consulter tes liens des que j'aurais une minute!
Pour gagner du temps dans des appels de fonctions ou même si je calcule plusieurs fois la même chose, je stocke le résultat dans une variable plutôt que de recalculer.
Par exemple si j'utilise plusieurs fois sin(pi/6), je déclare sinus30=sin(pi/6) et j'utilise directement la valeur. (sin30 car pi/6 vaut 30 degrés). C'est une évidence qu'il fallait peut-être rappelé.
Enfin si le programme tourne correctement et que l'on est satisfait de la vitesse d'exécution est-il vraiement nécessaire de rechercher l'optimisation : si l'affichage demandé arrive en 20 milli-secondes est-il impératif de l'avoir en 15 ?
Driss HANIB a écrit :
Salut Jean Marc (et Sébastien..)
Merci pour cet échange "technique" pour le moins, même si, du fait de mon
niveau, j'aurai du mal à appliquer tous ces conseils (je vais aller lire les
FAQ citées de suite.)
En tout cas ça décrasse les méninges..
Dans la même veine , contrairement au TROLL, j'utilise autant que faire ce
peut les procédures et les fonctions.
Jusqu'à quel point faire cela est-il utile ?
je m'explique : j'utilise cela dès que je pense qu'une action sera demandée
plusieurs fois, aussi bien dans la feuille en cours que dans d'autres. Mais
aussi, lorsque dans une fonction assez "complexe" (pour moi bien sûr), je
dois rajouter un traitement lui aussi compliqué. Alors je m'arrange pour
mettre ceci dans une procédure afin de gagner en "lisibilité".
Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à
appeler une procédure externe ?
je ne suis pas au point de réécrire tous les algorythmes, même si cela me
prend, mais je voudrai ne pas trop perdre en efficacité..
Merci
Driss
"jean-marc" <jean_marc_n2@yahoo.fr.invalid> a écrit dans le message de news:
48bf9ee9$0$2870$ba620e4c@news.skynet.be...
"Sebastien" <Sebastien.groulard@gmail.com> wrote in message
news:5849D312-A76D-4475-97ED-559B8C1849B6@microsoft.com...
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses
usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est
juste des cas ou il sera 'naturel' de l'employer.
Mais tu as raison, il n'est jamais plus perfomant qu'autre
chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement
clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Pour gagner du temps dans des appels de fonctions ou même si je calcule
plusieurs fois la même chose, je stocke le résultat dans une variable
plutôt que de recalculer.
Par exemple si j'utilise plusieurs fois sin(pi/6), je déclare
sinus30=sin(pi/6) et j'utilise directement la valeur. (sin30 car pi/6
vaut 30 degrés).
C'est une évidence qu'il fallait peut-être rappelé.
Enfin si le programme tourne correctement et que l'on est satisfait de
la vitesse d'exécution est-il vraiement nécessaire de rechercher
l'optimisation : si l'affichage demandé arrive en 20 milli-secondes
est-il impératif de l'avoir en 15 ?
Merci pour cet échange "technique" pour le moins, même si, du fait de mon niveau, j'aurai du mal à appliquer tous ces conseils (je vais aller lire les FAQ citées de suite.) En tout cas ça décrasse les méninges.. Dans la même veine , contrairement au TROLL, j'utilise autant que faire ce peut les procédures et les fonctions. Jusqu'à quel point faire cela est-il utile ? je m'explique : j'utilise cela dès que je pense qu'une action sera demandée plusieurs fois, aussi bien dans la feuille en cours que dans d'autres. Mais aussi, lorsque dans une fonction assez "complexe" (pour moi bien sûr), je dois rajouter un traitement lui aussi compliqué. Alors je m'arrange pour mettre ceci dans une procédure afin de gagner en "lisibilité". Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à appeler une procédure externe ? je ne suis pas au point de réécrire tous les algorythmes, même si cela me prend, mais je voudrai ne pas trop perdre en efficacité..
Merci
Driss
"jean-marc" a écrit dans le message de news: 48bf9ee9$0$2870$
"Sebastien" wrote in message news:
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est juste des cas ou il sera 'naturel' de l'employer. Mais tu as raison, il n'est jamais plus perfomant qu'autre chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :) Je manquerais pas de consulter tes liens des que j'aurais une minute!
Pour gagner du temps dans des appels de fonctions ou même si je calcule plusieurs fois la même chose, je stocke le résultat dans une variable plutôt que de recalculer.
Par exemple si j'utilise plusieurs fois sin(pi/6), je déclare sinus30=sin(pi/6) et j'utilise directement la valeur. (sin30 car pi/6 vaut 30 degrés). C'est une évidence qu'il fallait peut-être rappelé.
Enfin si le programme tourne correctement et que l'on est satisfait de la vitesse d'exécution est-il vraiement nécessaire de rechercher l'optimisation : si l'affichage demandé arrive en 20 milli-secondes est-il impératif de l'avoir en 15 ?
Jean-marc
Patrice Henrio wrote:
Driss HANIB a écrit :
Hello,
Pour gagner du temps dans des appels de fonctions ou même si je calcule plusieurs fois la même chose, je stocke le résultat dans une variable plutôt que de recalculer.
Par exemple si j'utilise plusieurs fois sin(pi/6), je déclare sinus30=sin(pi/6) et j'utilise directement la valeur. (sin30 car pi/6 vaut 30 degrés). C'est une évidence qu'il fallait peut-être rappelé.
Je pense en effet qu'il faut le rapeller, car c'est là évidemment une excellente pratique. Ca rejoint un des points dont je parlais: Précalculer tout ce qui peut l'être : faire du préprocessing.
Enfin si le programme tourne correctement et que l'on est satisfait de la vitesse d'exécution est-il vraiement nécessaire de rechercher l'optimisation : si l'affichage demandé arrive en 20 milli-secondes est-il impératif de l'avoir en 15 ?
Certainement pas. Et c'est bien la aussi que beaucoup se trompent : une optimisation doit être légitimée par des faits, et jamais entreprise pour le plaisir.
Pour gagner du temps dans des appels de fonctions ou même si je
calcule plusieurs fois la même chose, je stocke le résultat dans une
variable plutôt que de recalculer.
Par exemple si j'utilise plusieurs fois sin(pi/6), je déclare
sinus30=sin(pi/6) et j'utilise directement la valeur. (sin30 car pi/6
vaut 30 degrés).
C'est une évidence qu'il fallait peut-être rappelé.
Je pense en effet qu'il faut le rapeller, car c'est là évidemment une
excellente pratique. Ca rejoint un des points dont je parlais:
Précalculer tout ce qui peut l'être : faire du préprocessing.
Enfin si le programme tourne correctement et que l'on est satisfait de
la vitesse d'exécution est-il vraiement nécessaire de rechercher
l'optimisation : si l'affichage demandé arrive en 20 milli-secondes
est-il impératif de l'avoir en 15 ?
Certainement pas. Et c'est bien la aussi que beaucoup se trompent : une
optimisation doit être légitimée par des faits, et jamais entreprise
pour le plaisir.
Pour gagner du temps dans des appels de fonctions ou même si je calcule plusieurs fois la même chose, je stocke le résultat dans une variable plutôt que de recalculer.
Par exemple si j'utilise plusieurs fois sin(pi/6), je déclare sinus30=sin(pi/6) et j'utilise directement la valeur. (sin30 car pi/6 vaut 30 degrés). C'est une évidence qu'il fallait peut-être rappelé.
Je pense en effet qu'il faut le rapeller, car c'est là évidemment une excellente pratique. Ca rejoint un des points dont je parlais: Précalculer tout ce qui peut l'être : faire du préprocessing.
Enfin si le programme tourne correctement et que l'on est satisfait de la vitesse d'exécution est-il vraiement nécessaire de rechercher l'optimisation : si l'affichage demandé arrive en 20 milli-secondes est-il impératif de l'avoir en 15 ?
Certainement pas. Et c'est bien la aussi que beaucoup se trompent : une optimisation doit être légitimée par des faits, et jamais entreprise pour le plaisir.
Merci pour cet échange "technique" pour le moins, même si, du fait de mon niveau, j'aurai du mal à appliquer tous ces conseils (je vais aller lire les FAQ citées de suite.) En tout cas ça décrasse les méninges.. Dans la même veine , contrairement au TROLL, j'utilise autant que faire ce peut les procédures et les fonctions. Jusqu'à quel point faire cela est-il utile ? je m'explique : j'utilise cela dès que je pense qu'une action sera demandée plusieurs fois, aussi bien dans la feuille en cours que dans d'autres. Mais aussi, lorsque dans une fonction assez "complexe" (pour moi bien sûr), je dois rajouter un traitement lui aussi compliqué. Alors je m'arrange pour mettre ceci dans une procédure afin de gagner en "lisibilité". Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à appeler une procédure externe ?
Oui et non. Comem Sébastien l'a expliqué, il y a perte de temps à cause de l'empilement/dépilement des paramètres, etc.
MAIS cette perte est toute relative, sauf si on devait appeler la ou les procédures des centaines de millions de fois. SInon, on parle de dizièmes de microsecondes (1e-7) et c'est évidemment négligeable.
Et bien sur, dans tous les cas (sauf applications "temps réel" ultra pointues), la lisibilité doit primer sur tout. Ce n'est PAS (et ce ne sera JAMAIS) en écrivant du code compacté/crado qu'on gagnera quoique ce soit en perfs, sauf (je dis bien sauf) cas très très particuliers qui à mon avis dépassent de très loin le cadre de cd NG. Dans le cas général, on gagne en perfs (si besoin) en utilisant de meilleurs algos, de meilleures structures, plus de préprocesing, etc.
je ne suis pas au point de réécrire tous les algorythmes, même si cela me prend, mais je voudrai ne pas trop perdre en efficacité..
Tu ne perdras jamais en efficacité en écrivant proprement, en utilisant des focntions, etc. SAUF cas particuliers, très certainement hors-sujet ici.
Les articles de la FAQ que je citais dans l'article précédent sont le meilleur exemple qui soit : du code clair, sans astuces, utilisant des fonctions et procédures mais qui permet sur des tâches courantes des gains de 500 à 1000%, voire bien plus.
Merci pour cet échange "technique" pour le moins, même si, du fait de
mon niveau, j'aurai du mal à appliquer tous ces conseils (je vais
aller lire les FAQ citées de suite.)
En tout cas ça décrasse les méninges..
Dans la même veine , contrairement au TROLL, j'utilise autant que
faire ce peut les procédures et les fonctions.
Jusqu'à quel point faire cela est-il utile ?
je m'explique : j'utilise cela dès que je pense qu'une action sera
demandée plusieurs fois, aussi bien dans la feuille en cours que dans
d'autres. Mais aussi, lorsque dans une fonction assez "complexe"
(pour moi bien sûr), je dois rajouter un traitement lui aussi
compliqué. Alors je m'arrange pour mettre ceci dans une procédure
afin de gagner en "lisibilité". Mais perd t'on comme le dis Sebastien
beaucoup de cycles ou de temps à
appeler une procédure externe ?
Oui et non. Comem Sébastien l'a expliqué, il y a perte de temps à cause
de l'empilement/dépilement des paramètres, etc.
MAIS cette perte est toute relative, sauf si on devait appeler la ou
les procédures des centaines de millions de fois. SInon, on parle
de dizièmes de microsecondes (1e-7) et c'est évidemment négligeable.
Et bien sur, dans tous les cas (sauf applications "temps réel" ultra
pointues), la lisibilité doit primer sur tout. Ce n'est PAS (et ce ne
sera JAMAIS) en écrivant du code compacté/crado qu'on gagnera quoique
ce soit en perfs, sauf (je dis bien sauf) cas très très particuliers
qui à mon avis dépassent de très loin le cadre de cd NG. Dans le cas
général, on gagne en perfs (si besoin) en utilisant de meilleurs algos,
de meilleures structures, plus de préprocesing, etc.
je ne suis pas au point de réécrire tous les algorythmes, même si
cela me prend, mais je voudrai ne pas trop perdre en efficacité..
Tu ne perdras jamais en efficacité en écrivant proprement, en utilisant
des focntions, etc. SAUF cas particuliers, très certainement hors-sujet
ici.
Les articles de la FAQ que je citais dans l'article précédent sont le
meilleur exemple qui soit : du code clair, sans astuces, utilisant
des fonctions et procédures mais qui permet sur des tâches courantes
des gains de 500 à 1000%, voire bien plus.
Merci pour cet échange "technique" pour le moins, même si, du fait de mon niveau, j'aurai du mal à appliquer tous ces conseils (je vais aller lire les FAQ citées de suite.) En tout cas ça décrasse les méninges.. Dans la même veine , contrairement au TROLL, j'utilise autant que faire ce peut les procédures et les fonctions. Jusqu'à quel point faire cela est-il utile ? je m'explique : j'utilise cela dès que je pense qu'une action sera demandée plusieurs fois, aussi bien dans la feuille en cours que dans d'autres. Mais aussi, lorsque dans une fonction assez "complexe" (pour moi bien sûr), je dois rajouter un traitement lui aussi compliqué. Alors je m'arrange pour mettre ceci dans une procédure afin de gagner en "lisibilité". Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à appeler une procédure externe ?
Oui et non. Comem Sébastien l'a expliqué, il y a perte de temps à cause de l'empilement/dépilement des paramètres, etc.
MAIS cette perte est toute relative, sauf si on devait appeler la ou les procédures des centaines de millions de fois. SInon, on parle de dizièmes de microsecondes (1e-7) et c'est évidemment négligeable.
Et bien sur, dans tous les cas (sauf applications "temps réel" ultra pointues), la lisibilité doit primer sur tout. Ce n'est PAS (et ce ne sera JAMAIS) en écrivant du code compacté/crado qu'on gagnera quoique ce soit en perfs, sauf (je dis bien sauf) cas très très particuliers qui à mon avis dépassent de très loin le cadre de cd NG. Dans le cas général, on gagne en perfs (si besoin) en utilisant de meilleurs algos, de meilleures structures, plus de préprocesing, etc.
je ne suis pas au point de réécrire tous les algorythmes, même si cela me prend, mais je voudrai ne pas trop perdre en efficacité..
Tu ne perdras jamais en efficacité en écrivant proprement, en utilisant des focntions, etc. SAUF cas particuliers, très certainement hors-sujet ici.
Les articles de la FAQ que je citais dans l'article précédent sont le meilleur exemple qui soit : du code clair, sans astuces, utilisant des fonctions et procédures mais qui permet sur des tâches courantes des gains de 500 à 1000%, voire bien plus.
Merci à Patrice,Sébastien, Jean-Marc..(l'ordre importe peu) pour ces précisions. Je ne cherche pas à optimiser pour optimiser, car d'une part je n'ai sans doute pas les compétences puisqu'autodidacte et surtout par ce qu'effectivement je ne fais pas les mêmes actions des millions de fois. C'est juste poiur comprendre uin peu et ne pas prendre de trop mauvaises habitudes. Merci Patrice pour ta correction entre "ALGORITHME et non ALGORYTHME". Une étourderie.. Je reste à votre écoute et à votre expertise.. et petit à petit j'apprends.
Driss
"jean-marc" a écrit dans le message de news: 48bf9ee9$0$2870$
"Sebastien" wrote in message news:
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est juste des cas ou il sera 'naturel' de l'employer. Mais tu as raison, il n'est jamais plus perfomant qu'autre chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :) Je manquerais pas de consulter tes liens des que j'aurais une minute!
Merci à Patrice,Sébastien, Jean-Marc..(l'ordre importe peu) pour ces
précisions.
Je ne cherche pas à optimiser pour optimiser, car d'une part je n'ai sans
doute pas les compétences puisqu'autodidacte et surtout par ce
qu'effectivement je ne fais pas les mêmes actions des millions de fois.
C'est juste poiur comprendre uin peu et ne pas prendre de trop mauvaises
habitudes.
Merci Patrice pour ta correction entre "ALGORITHME et non ALGORYTHME".
Une étourderie..
Je reste à votre écoute et à votre expertise.. et petit à petit j'apprends.
Driss
"jean-marc" <jean_marc_n2@yahoo.fr.invalid> a écrit dans le message de news:
48bf9ee9$0$2870$ba620e4c@news.skynet.be...
"Sebastien" <Sebastien.groulard@gmail.com> wrote in message
news:5849D312-A76D-4475-97ED-559B8C1849B6@microsoft.com...
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses
usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est
juste des cas ou il sera 'naturel' de l'employer.
Mais tu as raison, il n'est jamais plus perfomant qu'autre
chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement
clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Merci à Patrice,Sébastien, Jean-Marc..(l'ordre importe peu) pour ces précisions. Je ne cherche pas à optimiser pour optimiser, car d'une part je n'ai sans doute pas les compétences puisqu'autodidacte et surtout par ce qu'effectivement je ne fais pas les mêmes actions des millions de fois. C'est juste poiur comprendre uin peu et ne pas prendre de trop mauvaises habitudes. Merci Patrice pour ta correction entre "ALGORITHME et non ALGORYTHME". Une étourderie.. Je reste à votre écoute et à votre expertise.. et petit à petit j'apprends.
Driss
"jean-marc" a écrit dans le message de news: 48bf9ee9$0$2870$
"Sebastien" wrote in message news:
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est juste des cas ou il sera 'naturel' de l'employer. Mais tu as raison, il n'est jamais plus perfomant qu'autre chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :) Je manquerais pas de consulter tes liens des que j'aurais une minute!
