ATOUTFOX
COMMUNAUTÉ FRANCOPHONE DES PROFESSIONNELS FOXPRO
Visual FoxPro : le développement durable

Optimiser son code Visual FoxPro   



L'auteur

FoxInCloud
France France
Membre Simple
# 0000000014
enregistré le 13/10/2004

http://www.foxincloud.com/
Nivelet Thierry
75016 Paris
de la société Abaque
Fiche personnelle


Note des membres
18/20
1 vote


Contributions > 20 - Trucs et Astuces

Optimiser son code Visual FoxPro
# 0000000446
ajouté le 24/05/2007 13:40:22 et modifié le 04/06/2007
consulté 6180 fois
Niveau initié

Version(s) Foxpro :
VFP 9.0
VFP 8.0
VFP 7.0
VFP 6.0
VFP 5.0
VFP 3.0
FPW 2.6
FPD 2.x

Description
Rushmore d'abord
Concerne toute action qui cible des enregistrements selon une condition, comme par exemple :
SELECT-SQL... WHERE expr
UPDATE-SQL...WHERE expr
REPLACE ... FOR expr
SCAN ... FOR expr

Si un la table comporte un index sur expr, VFP va lire l'index au lieu de parcourir toute la table à la recherche des enregistrements satisfaisant expr, les temps d'exécution sont facilement divisés par 100 (le gain augmente avec le nombre d'enregistrements)

Moins de variables
Comme tout langage dynamique, VFP résoud à l'exécution (at runtime) les noms de :
  • variable,
  • champ,
  • alias,
  • table,
  • fichier,
  • classe,
  • objet,
  • etc.
En particulier Il cherche les variables dans une liste qu'il entretient en interne... Plus courte est cette liste plus rapidement il trouve.
Ne pas hésiter à RELEASEr les variables des programmes de haut niveau pour raccourcir la liste ... et surtout déclarer les variable en LOCAL pour éviter de polluer les programmes appelés.

Penser à m.variable
Avec sa BD intégrée, VFP cherche d'abord dans la table courante avant de chercher dans les variables.
Le préfixe "m." lui évite de parcourir la liste des champs de la table courante, et une éventuelle confusion entre une variable et un champ qui porte le même nom (indispensable en cas de SCATTER MEMVAR).
Utile en lecture seulement ... aucune confusion possible en écriture puisque pour un champ il faut utiliser REPLACE ou UPDATE.

Des noms courts
Comme la plupart des langages MS, VFP est insensible à la casse (case insensitive).
Avant de chercher un nom, il doit le passer dans la casse où il l'a stocké (upper dans la plupart des cas)
Plus les noms noms sont courts, plus cette opération est rapide.

Subtile substitution
Comme tout langage dynamique, VFP résoud les noms à l'exécution et permet l'exécution de code dynamique (programme qui génère un programme).
Dans l'immense majorité des cas, nous créons des noms à l'exécution, parfois des expressions, moins souvent nous créons des instructions.
  • Pour évaluer un nom à l'exécution : substitution de nom par (m.Variable) - à privilégier
  • Pour évaluer une expression à l'exécution : result = evaluate(m.Variable)
  • Pour évaluer tout ou partie d'une instrution à l'exécution : macro substitution par &Variable
  • Pour évaluer plusieurs instrutions à l'exécution : execScript(m.Variable)
Code source :
LOCAL Variable
Variable = "NomFich" && "m." inutile
LOCAL (m.Variable) && substitution de nom - crée une variable locale "NomFich"
? m.NomFich && affiche .F.
STORE "c:\test.txt" to (m.Variable) && substitution de nom, NomFich est remplie
? m.NomFich && affiche bien "c:\test.txt"
StrToFile('test', (m.NomFich)) && crée le fichier "c:\test.txt" et y écrit "test"

Commentaires
le 28/05/2007, Robert Plagnard a écrit :
Bonjour Thierry,
Des tests ont ils été effectués pour mesurer l'impact de la longueur des noms de variables sur les temps d'exécution ? Car je suis sceptique.
En effet dans le code compilé (tant qu'il n'y a pas de macro), les variables sont toutes codées sur 2 octets. Que l'on écrive i = m.i + 1 ou iQuiEstVraimentLong = m.iQuiEstVraimentLong + 1, on compile dans un code qui est exactement le même dans les 2 cas. Et à mon avis, la vitesse devrait être la même par définition.
Je serais plutot pour mettre des noms dont la longueur serait proportionnelle au scope de la variable. Si la variable est hyper locale (ex: une boucle de 3 lignes) alors il n'y a vraiment pas d'inconvénient à l'appeler i, j ou k. (Dans certains langage comme FORTH c'était même gravé dans le marbre, l'indice de la boucle la plus externe était obligatoirement i, puis celui d'une boucle interne j et ainsi de suite). A l'opposé, si la variable traverse une grande partie de l'application (mais ça n'arrive jamais!) alors il faut lui trouver un nom bien significatif.
Cordialement,
Robert

le 01/06/2007, FoxInCloud a écrit :
Bonjour Robert,
J'avoue avoir péché par méconnaissance ... tu as sans doute raison.
Mais dans le cas où on utilise la substitution (de nom ou macro), VFP doit bien stocker quelque part le nom de la variable, non ?
Comme cette substitution peut porter sur le nom d'une variable privée d'un module appelant (indétectable à la compilation), il doit bien entretenir une liste de noms de variables, même s'il l'associe à un code sur 2 octets dans le code compilé (pour gagner de la place probablement).
Aussi je pense que le mécanisme que je décris doit bien avoir lieu quelque part ...
Qu'en penses-tu ?
@ +

le 01/06/2007, eddymaue a écrit :
N'est il pas préférable d'employer Eval(MonExpression) au lieu &MonExpression
le 04/06/2007, FoxInCloud a écrit :
Bonjour Eddy
Tu as parfaitement raison, je savais que j'avais oublié quelque chose, c'est eval()
A utiliser sans modération pour évaluer une EXPRESSION stockée dans une variable ou un champ !

le 30/09/2007, bd a écrit :
Le point entre le m et la variable est-il insdispensable ?
Comment réagit VFP en rencontrant "mVariable" au lieu de "m.Variable" ?
Merci

le 01/10/2007, FredA a écrit :
De la même manière qu'entre Variable et m.Variable (c'est à dire entre m.mVariable et mVariable)...
Le point est bien nécessaire dans ce cas.


Publicité

Les pubs en cours :

www.atoutfox.org - Site de la Communauté Francophone des Professionnels FoxPro - v3.4.0 - © 2004-2017.
Cette page est générée par un composant COM+ développé en Visual FoxPro 9.0