Discussion :

[AlfredKr]

Bonjour,

J'ai une procédure b imbriquée dans la procédure a.
J'ai des variables locales x, y, z dans b et celle-ci sera appelée des milliers de fois tandis que a ne sera appelée qu'une fois au départ.
Où définir x, y, z pour que le temps d'exécution diminue ? dans a ou dans b ?

Merci d'avance,

fred

[Nono40]

Tout dépend des types de variables :

Type scalaires : Dans b
Car si elles sont transformées en registre CPU par l'optomisation ça gagnera plus de temps. Si elles ne le sont pas le temps sera le même car l'accès à une variable locale de a ou de b une fois compilé revient toujours à un [EBP+offset]

Type chaines/tableaux dynamiques : dans a
La règle ci-dessus va s'appliquer, mais en plus à chaque appel de B du code d'initialisation et de finalisation sera ajouté implicitement par le compilateur.

Objets (comme un TStringList de travail) : Dans a
Même principe que pour le cas ci-dessus sauf que c'est toi qui ajoute explicitement le code d'initialization/finalisation.

[AlfredKr]

Bravo Mr NONO, répondre à 3H30 du mat, c'est beau sauf si vous êtes comme moi "loin" de France....
Bon, ce sont des entiers et réels, il n'y en a pas beaucoup (6 en tout), je les définirai donc dans b. Mais c'était une question + générale sur l'emplacement optimal. De plus il vaut mieux les garder dans b pour une meilleure lisibilité du programme.

Merci encore,

Fred

[Nono40]

Non non je suis bien un Français en France. Mais je n'ai pas des horaires 'normaux'

Qu'est ce que tu fais comme type de calcul dans B ?

[Paul TOTH]

attention tout de même, l'appel d'une variable locale à a depuis b demande une référence de plus; on va chercher dans la pile de l'appelant et pas simplement à un offset donné, en effet b pourrait être appelé récursivement, ou depuis d'autres fonctions locales à a...avec une pile dans un état différent à chaque fois et un offset qui ne veux plus rien dire.

[AlfredKr]

Excusez-moi, je croyais que la discussion était fermée puisque j'ai eu une réponse à ma question.
Mon programme est la simulation d'un séisme horizontal sur un pont protégé par des dispositifs parasismiques.
Dans b, je calcule les forces fournies par différents éléments à chaque pas de temps de calcul, sachant que le temps total d'un séisme est d'environ 30s et que le pas de temps de calcul est inférieur à 0.1ms.

Fred

[AlfredKr]

J'ajouterai que, comme l'envisageait Mr Paul TOTH, b est appelé à différents endroits de a (qui est la procédure principale du calcul).

Fred

[Nebulix]

Où définir x, y, z pour que le temps d'exécution diminue ? dans a ou dans b ?

Il ne doit pas être très difficile de programmer les deux méthodes, ni de mesurer les temps d'éxécution.
Par contre il doit être beaucoup plus difficile de mesurer une différence, tant elle doit être petite.
Tu essaies et tu nous tiens au courant ?
Merci

[AlfredKr]

Bonjour Nebulix,

C'est ce que je voulais faire hier après avoir envoyé mes réponses. Dès que je l'aurai mesuré, je vous tiendrai au courant.

Fred

[Dr.Who]

si c'est la performance que tu cherche il ne faut surtout pas utiliser de fonction locale.

car à chaque calcul on se retrouve avec un CALL qui est anti-performant.

soit tu utilise une fonction externe (portée globale) mais INLINE (D2009/D2010)
soit tu intègre la fonction à la boucle.

le mieux aurait été de nous montrer le code pour pouvoir t'indiquer toutes les optimisations faisable.

[AlfredKr]

Merci pour ta réponse, Dr Who.
Je ne sais pas ce qu'est une fonction externe inline.
Inline voulait dire "à définir sur une ligne" en C++ je crois,
est-ce pareil en delphi (2010) ? ma fonction b est longue d'environ 100 lignes. elle apparaît 5 fois dans la fonction a, donc la ré-ecrire 4 fois, me semble lourd mais envisageable (je perds l'intérêt d'utiliser une fonction.
Pour vous montrer la procédure a, je veux bien, mais elle utilise des éléments finis et est tout un calcul de résolution d'un système d'équations différentielles du 2eme ordre qui n'a pas d'intérêt dans ce forum. De plus la proc est trop longue.

Fred

[sjrd]

Pour vous montrer la procédure a, je veux bien, mais elle utilise des éléments finis et est tout un calcul de résolution d'un système d'équations différentielles du 2eme ordre qui n'a pas d'intérêt dans ce forum. De plus la proc est trop longue.

Eh bien tu as ta réponse : ce n'est l'overhead d'appel de ta procédure B qui est le bottleneck de tes performances. Il faut voir de manière globale une optimisation plus drastique.