Discussion :

[Gordon72]

Bonjour tout le monde,

J'ai plusieurs fonctions qui nécessitent d'utiliser un même tableau composé de 55 nombres double. Plutôt que de recréer le même tableau dans chacune des ces fonctions, j'ai créé une fonction "monTableau" qui renvoie "monTableau = Array(....)". Ainsi cela me permet de créer ce tableau une seule fois et de l'appeler dans toutes mes autres fonctions.

Je me pose donc certaines questions :

1 - Mettre un tableau sous forme de fonction et l'appeler dans d'autres fonctions consomme-t-il plus de temps que de mettre directement le tableau dans chaque fonction ?
2 - VBA n'étant pas un langage compilé, mais lu ligne par ligne je me demande si le fait de mettre plusieurs fonctions dans le même modules fait que VBA calcul avant tout ce qui est avant ma fonction ?

Si vous voulez je peux mettre des exemples en fichier.

Merci de votre aide.

[NVCfrm]

...
1 - Mettre un tableau sous forme de fonction et l'appeler dans d'autres fonctions consomme-t-il plus de temps que de mettre directement le tableau dans chaque fonction ?
2 - VBA n'étant pas un langage compilé, mais lu ligne par ligne je me demande si le fait de mettre plusieurs fonctions dans le même modules fait que VBA calcul avant tout ce qui est avant ma fonction ?
...
Merci de votre aide.

Réponse 1: Sans doute qu'en écrivant cette question, tu dois deviner plus ou moins la réponse.
Ensuite cela dépend de comment ta fonction renvoi un tableau.
C'est à dire une variable locale à la fonction, de portée module, ou du projet. Pour le premier tu dois toujours savoir (du moins c'est ce que je crois) que c'est un peu semblable à créer un tableau dans le sub appelant. L'intérêt étant selon les cas, l'allègement du code, la lisibilité ... Pour les 2 autres cas, c'est quoi à ton avis ?

Réponse 2 : Le compilateur à des optimisations, lui permettant d'anticiper , mise en cache des lignes compilées etc. pour que tu t'aperçoives pas d'une quelconque interprétation.
VBA est aussi un langage objet. Il est préférable à la place d'une fonction pour une variable publique, de créer une procédure Public Property, même si c'est dans un module standard.

[Gordon72]

Bonsoir NVCfrm,

Déjà merci pour votre aide.

Pour faire simple j'ai créé deux bouts de code (avec des valeurs totalement inventées).

Code 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Option Base 1
 
Private Function monTableau()
 
monTableau = Array(22, 10, 15, 159, 0.253547145642257 * 10^ - 12, 3.1156 * 10^ - 57)
 
End Function
 
Function maFonction1(ByVal x As Double) As Double
 
For i = 1 To 6
    maFonction1 = maFonction1 + monTableau(i) * x
Next
 
End Function
 
Function maFonction2(ByVal x As Double) As Double
 
For i = 1 To 6
    maFonction2 = maFonction2 + monTableau(i) * 2 * x
Next
 
End Function

Code 2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Option Base 1
 
Function maFonction1(ByVal x As Double) As Double
 
monTableau = Array(22, 10, 15, 159, 0.253547145642257 * 10^ - 12, 3.1156 * 10^ - 57)
For i = 1 To 6
    maFonction1 = maFonction1 + monTableau(i) * x
Next
 
End Function
 
Function maFonction2(ByVal x As Double) As Double
 
monTableau = Array(22, 10, 15, 159, 0.253547145642257 * 10^ - 12, 3.1156 * 10^ - 57)
For i = 1 To 6
    maFonction2 = maFonction2 + monTableau(i) * 2 * x
Next
 
End Function

Selon moi le code 2 est plus rapide que le 1 car on évite d'appeler 6 fois la fonction monTableau dans la boucle For. J'ai juste ?

La seconde question que je me pose est la suivante : si j'ai mes deux fonctions de calcul dans le même module et que je souhaite calculer uniquement maFonction2, est-ce que VBA (lisant ligne par ligne) va perdre du temps à calculer maFonction1 avant de calculer maFonction2 ? En gros est-ce qu'un module par fonction est plus rapide que plusieurs fonctions dans le même module ?

Merci de votre aide.

[unparia]

Bonjour

j'ai créé une fonction "monTableau" qui renvoie "monTableau = Array(....)"

présente un intérêt certain, mais à la condition que le tableau retourné soit immuable.
Si tel est le cas, ta fonction n'est alors utile que si elle retourne un tableau à portée générale.
Or ta fonction ne retourne rien et on ne sait pas où et comment tu as déclaré le tableau montableau.
Je n'ai pas analysé le reste.

[Gordon72]

Bonsoir umparia,

... comment tu as déclaré le tableau montableau

C'est dans mon dernier message.

Sinon oui monTableau est immuable et est déclaré dans le même module où sont placées les fonctions qui réutilisent ce tableau. Là j'ai mis un exemple bidon mais en réalité je dois avoir une dizaine de fonctions contenant des boucles For qui à chaque itération vont chercher monTableau(i) dans la boucle

[unparia]

C'est dans mon dernier message

Non. Moi, je vois que c'est une fonction et qu'elle ne retourne rien qui puisse se conserver et être à nouveau invoqué.

[unparia]

Fais ce test (avec deux boutons de commande commanbutton1 et commandbutton2)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Private montableau ' je déclare ma variable montableau
 
Private Sub CommandButton1_Click()
  montableau = faire_montableau() ' je lui affecte son contenu (nul besoin de l'affecter x fois)
End Sub
Private Function faire_montableau()
  faire_montableau = Array("a", "b", "c") ' voilà son affectation
End Function
 
Private Sub CommandButton2_Click()
 'je n'ai pas besoin de relancer ma fonjction faire_montableau. montableau est déjà là et rempli
 For i = 0 To UBound(montableau)
  MsgBox montableau(i)
 Next
End Sub

Clique ensuite sur commanbutton1
Clique ensuite sur commandbutton2, autant de fois que tu voudras. Plus besoin de relancer la fonction. Une fois a suffi.
Analyse et comprends

[Gordon72]

Juste une mise au point car j'ai un peu peur qu'on diverge de mes questions principales là (bon en fait on est peut-être justement en plein dedans et je ne le comprends pas aussi)

J'ai fais un fichier .xla qui contient des fonctions renvoyant les propriétés d'un gaz pour n'importe quelle pression ou température. J'ai pour cela des fonctions de calcul qui renvoient des masses volumiques, des enthalpies... Certaines de ces fonctions réutilisent des tableaux communs.
Je cherche juste à savoir la solution qui réduit le temps de calcul au maximum (tableau dans une fonction unique séparée que j'appel depuis mes fonctions masse volumique, enthalpie... ou tableau directement implémenté dans chaque fonction...)

Au final ta solution permet-elle un calcul plus rapide que le code ci-dessous ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
 
Private Sub CommandButton2_Click()
montableau = Array("a", "b", "c") 
 For i = 0 To UBound(montableau)
  MsgBox montableau(i)
 Next
End Sub

[unparia]

Au final ta solution permet-elle un calcul plus rapide que le code ci-dessous ?

Pas vraiment. En out état de cause pas de manière significative avec cet exemple-là.
Mais c'est toi qui a posé la question de différence en gain de temps.
Si, maintenant, ta fonction est plus complexe (calculs, etc ... en vue de remplir ton tableau) : oui, alors : gros gain de temps.
Tout le reste n'est que question d'organisation adaptée à des besoins déterminés. Et cet aspect-là relève de la conception.

[clementmarcotte]

Bonjour,

Je vais encore radoter une chose importante. Excel a toujours besoin de tous les classeurs qu'Il a ouverts en mémoire vive. Cela fait qu'au final la mémoire vive disponible devient un élément indispensable de la performance. Il suffit qu'un autre programme qu'Excel vienne gruger la mémoire utilisée par Excel pour saboter à peu près toutes les passes (droite ou croches) qui peuvent être essayées pour accélérer une procédure VBA.

Et puis, encore du radotage. Avec Visual Studio Community qui est gratuit, on peut réaliser des applications autonomes compilées ou des compléments compilés pour les applications Office. Prendre toutes les macros qui utilisent le même tableau et en faire une DLL compilée pour Excel dans Visual Studio, ou même une application complètement autonome qui ferait juste lire le tableau Excel, comme si c'était une base de données Access ou SQLServer (c'est exactement le même principe, il faut juste changer les objets et les pilotes), ou même d'un vulgaire fichier XML est probablement une des meilleures choses à faire. Et cela se fait par du monde. Faut juste vouloir faire l'effort.

Mais comme certains autres, je parle dans le beurre.

[Gordon72]

Mais comme certains autres, je parle dans le beurre.

Si c'est à moi que tu fais référence sache que tu ne parles pas dans le beurre... bien au contraire je suis grandement reconnaissant et à l'écoute des gens qui m'aident alors qu'ils n'en ont pas l'obligation.

Maintenant pour être honnête la partie dll j'y ai pensé car fut un temps j'avais fait de petites fonctions en dll. Le problème est qu'en C++ je ne connais que les bases (boucle, pointeurs, classes...). Je sais mettre une petite fonction dans une dll mais pas une grosse fonction avec des appels de tableaux et tout.

Sinon umparia je vois où tu veux en venir avec ton exemple. Ce qui fait la différence à mon avis est que mes fonctions sont plutôt simples et peuvent être appelées dans n'importe qu'elle ordre (ou même pas appelées du tout). Ca dépendra uniquement de ce que veut calculer l'utilisateur. Par contre ton exemple me sera bien utile pour un autre programme (je ne connaissais pas ta méthode qui consiste à "charger" une fois un élément pour le réutiliser).

[clementmarcotte]

Bonjour,

Si c'est à moi que tu fais référence sache que tu ne parles pas dans le beurre... bien au contraire je suis grandement reconnaissant et à l'écoute des gens qui m'aident alors qu'ils n'en ont pas l'obligation.

Non ce n'est pas toi. Le beurre c'est l'ensemble des gens qui s'obstinent â vouloir utiliser Excel pour des choses pour lesquelles il n'a pas été conçu et qui croient que c'est une obligation de leur trouver quand même une solution. Même si c'est comme vouloir un psychiâtre pour installer une prothèse de la hanche.à

[Gordon72]

D'accord ^^. En tout cas moi personnellement mon programme marche et VBA me va très bien pour faire mes calculs. Mon post à la base était juste pour savoir si il était possible d'optimiser un peu ces temps de calcul :

1 - en mettant les tableaux dans les fonctions de calcul plutôt que dans des fonctions séparées renvoyant un tableau
2 - en mettant une seule fonction par module

La réponse à la question 1 m'a été donnée. Maintenant pour la question 2, je cherche juste à savoir si lorsque j'ai plusieurs fonctions dans le même module Excel me calcul tout ce qu'il y a avant ma fonction dans ce même module (car il lit ligne par ligne) ou si il va directement vers ma fonction.

[unparia]

Maintenant pour la question 2, je cherche juste à savoir si lorsque j'ai plusieurs fonctions dans le même module Excel me calcul tout ce qu'il y a avant ma fonction dans ce même module (car il lit ligne par ligne) ou si il va directement vers ma fonction.

cette question me fait douter un peu de ce que tu entends par "module" et par "fonction".
Un module est un module de code. Il est composé :
- d'une partie générale destinée aux déclarations et donc hors toutes procédures
- de procédures diverses ("subs" et "functions"), qui ne s'exécutent pas dans tel ou tel ordre, mais lorsqu'elles sont appelées (en général depuis une procédure évènementielle. Une procédure appelée depuis une procédure évènementielles peut elle-même appeler une autre procédure, etc ...)
- chaque procédure contient des lignes de code qui sont des instructions. Ces instructions sont exécutées une par une et dans l'ordre de ces lignes de code.

Est-ce que c'est ainsi maintenant clair ?
EDIT : exwemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Private Sub CommandButton1_Click() ' procédure évènementielle (on a cliqué sur un bouton de commande
  toto ' on déclenche la procédure toto
  msgbox "compris ?"
end sub
 
private sub toto
  titi
  tata
  msgbox "vu ?"
end sub
 
private sub titi
  msgbox "bonjour"
  msgbox "voilà"
end sub
private sub tata
 msgbox "hello"
 msgbox "that's it"
end sub

fait que si tu cliques sur le bouton de commande, tu verras s'afficher successivement : "bonjour", puis "voilà", puizs "hello", puis "that's it", puis "vu ?", puis "compris ?"

VBA ne se prête par ailleurs pas à du multithreading
-

[Gordon72]

Bonjour umparia,

Oui je considère bien un module comme la partie où tu peux placer tes fonctions, sub... On m'a toujours dit que VBA était plus long que du compilé car il lisait ligne par ligne. Alors je me demandais juste si par exemple tu as plusieurs Sub les dans le même module et que tu appelles l'un d'entre eux, est-ce que VBA va d'abord perdre son temps à lire tous les sub que tu as dans le module avant d'arriver au tiens et de l’exécuter.

[unparia]

Il me semble t'avoir répondu plus haut de la manière la plus claire.

EDIT : je ne comprends donc pas ta question.
L'ordre dans lequel les procédures sont écrites n'a aucune importance. Chaque procédure a son adresse. Qu'elle apparaisse la 1ère ou la dernière dans l'écriture ne change rien au fait quj'il va falloir aller à cette adresse associée. Et le logiciel s'y rend directement, sans faire de "petites étapes" dont il n'a que faire.

[clementmarcotte]

Bonjour,

Un peu dans la même veine que unparia.

Dans VBA, et c'est le propre de tout langage interprété, les instructions sont "recompilées" à chaque passage et tous les sauts sont immédiatement effectués, sans égard à l'ordre des instructions.

Dans un langage compilé, les instructions sont compilées en une seule fois et réaménagées par le compilateur selon une logique qui lui est propre.

Pour la petite histoire, même si des vieux me traitent de jeune homme, Microsoft a introduit dans QuickBasic, l'ancêtre de QBasic des dernières versions de MS-DOS une technique qui faisait que l'exe final était compilé mais qu'en phase conception et débogage, le programme avait un comportement semblable à celui d'un programme interprété. Et cette technique, ou une technique similaire a été maintenue dans Microsoft .net

C'est pour cela que je pense que tu aurais avantage de passer en VB.net. Même si tu ne peux pas espérer une intégration totale et sans erreurs, tu pourrais reprendre ton (tes) modules VBA et en faire une transition vers des programmes compilés. Soit comme une "macro complmentaire compilée", soit comme une application totalement autonome.

[Gordon72]

Bonjour à vous,

Merci bcp pour vos réponses. C'est tout à fait clair pour moi désormais. Et désolé si mes questions sont sans doutes un peu "cucul" mais pour être honnête moi je ne suis pas du tout dans la programmation. Je l'utilise seulement pour mes calculs et il est vrai que même si je suis capable de programmer certaines choses, je suis parfois ignorant de certaines bases qui peuvent paraître anodines pour vous.

Merci encore pour vos conseils et votre patience xD.

Bonne journée.