Discussion :

[freud]

Bonjour,

Quand on a plusieurs boucles FOR et WHILE imbriquées ça met un certain temps pour exécuter un traitement. Existe-t-il une option dans l'IDE de D7 pour réduire ce temps ?

Merci.

[SergioMaster]

Bonjour,

Quel rapport avec l'IDE ? le temps d'exécution dépendra des traitements a effectuer. Maintenant si certains traitements peuvent être fait dans des threads alors le temps d'exécution global diminuera peut-être ! la question est trop vague (plusieurs boucles For While imbriquées ) en tout cas, AMHA, ce n'est pas dans l'IDE qu'il faut chercher une réponse

[ShaiLeTroll]

En Débogage sous Delphi, cela sera plus lent qu'une version Release, à part ça, l'IDE n'a pas d'influence

En D7, si tu manipules des string ou des tableaux en les redimensionnant souvent, tu peux améliorer les performances de deux manières
- Allocation prédictive avec une gestion manuelle des bornes
- FastMM

Il nous faudrait du code pour savoir ce que l'on peut te proposer mais par exemple

Code :

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

1
2
for i := 0 to 1000 do
  S := S + 'A';

Ce code ci dessus est très lent et le code ci-dessus, sera 100 fois plus rapide car évite la réallocation de la chaine

Code :

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

1
2
3
4
 
SetLength(S, 1001);
for i := 0 to 1000 do
  S[i + 1] := 'A';

[anapurna]

salut

comme le dis SergioMaster c'est plus un problème de conception (algorithmie) que d'ide

je pense qu'il faut que tu revois tes condition d’arrêt de tes différentes boucles
je ne suis pas un fervent défenseur des break et autre joyeuseté qui permette une sortie de boucle rapide
mais il est évident que pour de la programmation rapide et jetable ceci est bien pratique

le FOR est une boucle particulière pour lequel on demande de parcourir Tout les éléments de l'ensemble
elle peut très bien être remplacé avantageusement par une boucle While

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
InCBoucle:= 0;
MaCond1 := (InCBoucle <= MavAlMax);
MaCond2 := False;
While (MaCond1 = true)  Do 
  //... je fais ce que j'ai a faire
 
   MaCond2 := OnDoitSortir(InCBoucle,MaVaraiable);
   Inc(InCBoucle);
   MaCond1 := (InCBoucle <= MavAlMax) and (MaCond2=False) ;
 end ;

[freud]

Re et merci pour vos réponses.
Bon alors si ce n'est pas l'IDE alors tant pis.
Non, je manipule des TQuery depuis lesquelles je récupère des string.
J'avais déjà remplacer certaines TQuery par des TkbmMemTable ca avait réduit un peu le temps de traitement ou peut-être que je ne les utilisent pas de façon optimale ?

[anapurna]

salut

pour la manipulation de query c'est peut etre tes requettes qu'il faut optimiser
voir si la table a les bon index
eviter le

Code :

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

select * from MATABLE

mais plutôt utiliser

Code :

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

select MONCHAMPS2,MONCHAMP3,... from MATABLE  where MES_CONDITIONS_RESTRICTIVE

[freud]

J'ai poster sans voir les autres posts ou peut-être ils se sont croisés.
Je me suis résèrver l'optimisation en dernier lieu au cas où je ne trouverais pas d'autres solutions.
J'utilise le strict minimum pour la récupération de champs et pas de :

Code :

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

1
2
 
SELECT * FROM ....

Mais peut-être qu'il faut revoir la disposition des boucles donc réanalyser.

Merci à vous tous !

[SergioMaster]

Re,

peut être que la query est mal ficelée d'où l'obligation de traitement ?
par exemple une boucle pour faire un cumul se remplace par un SUM() (avec à l'occasion un GROUP BY)
mais comme on reste dans le flou (même pas la SGBD) .....

[freud]

Ah pardon, pour le SGBD c'est BDE avec tables PDX parce qu'au départ j'avais pensé que c'etait une affaire de compilateur.

[SergioMaster]

Je ne reviendrai pas enfoncer le clou sur le BDE (obsolète)
pour ce qui est de Paradox , kbmem n'apporterait rien ou peu car Paradox travaille en mémoire, et le SQL proposé par Paradox est plus que limité !

tu ferais mieux d'ouvrir un nouveau sujet, dans "base de données", avec ce que fait une boucle ou ce que tu veux faire ,et la description de la/des table/s et on pourrait peut être te proposer une requête plus efficace

[ShaiLeTroll]

Ah la réponse va être plus simple ... ne plus utilisé BDE et Paradox !
C'est lent par nature !
Le SQL sous Paradox faut qu'il soit ciblé sur un tout petit lot d'enregistrement !
Il est parfois plus rapide d'utiliser un TTable et de boucler en Delphi que de passer par le SQL qui génère un fichier temporaire contenant le résultat

[guillemouze]

le FOR est une boucle particulière pour lequel on demande de parcourir Tout les éléments de l'ensemble
elle peut très bien être remplacé avantageusement par une boucle While

Le avantageusement n'est pas de circonstance. Un for sera toujours plus rapide qu'un while car la condition d'arret est évaluée une seul fois au démarrage de la boucle, alors que le while l'évalue à chaque itération.
Par contre, il faut utiliser un break pour en sortir sur un condition spéciale (je n'en suis pas fan non plus, mais je l'utilise avec parcimonie, en le mettant en exergue avec un code du genre
break; //------------- BREAK ---------------)

Comme le dit Sergio, je crois qu'il faudrait revoir ta query qui est peut être mal ficelée. Il me semble qu'une grosse requete sera plus efficace qu'une boucle qui effectue plein de petites requetes.

Autrement, dans l'IDE, options du projet > compilateur > optimisation te permet d'optimiser aussi les boucles quand c'est possible (boucle a l'envers car la comparaison à 0 est une instruction processeur directe par exemple)

[freud]

Je ne reviendrai pas enfoncer le clou sur le BDE (obsolète)

Je sais, je sais,...... j'avais déjà abandonner BDE pour FB mais quand on a des applic avec PDX faut bien chercher si y a moyen de dépasser cette limite.
Evidemment fallait poster au forum approprié mais n'avais pas pensé que c'etait un problème de BDD.

Il est parfois plus rapide d'utiliser un TTable et de boucler en Delphi

J'avais eviter les TTable à cause de sa lenteur en réseau ce qui oblige de fermer et de réouvrir les tables j'en avais fait une idée obstinément fixe d'eviter cela mais parfois on doit combiner. Mais après tout, ce n'est que pour une seule fonctionnalité et pas pour toutes l'appli alors je vais essayer avec les TTable. Merci ShaiLeTroll et à tous le monde. Je met donc résolu.

[ShaiLeTroll]

On n'est pas obligé de faire Close\Open, FlushBuffers coté écriture et Refresh côté lecteur font le boulot !
Mais je te confirme qu'en réseau avec un accès concurrentiel, il faut éviter le TTable et faire des SQL très ciblés
Aujourd'hui, j'ignore ce que cela donne mais sous Win98, les fichiers Paradox partagé avec le NetDir, WorkDir ... bien configuré, disons que 7 clients max, après ça se cassait la gueule si tu avais déjà accès très soutenu
Tu passais tes fichiers sur un serveur UNIX via un Samba, tu pouvais monter à 100 !

Toutes les applications que j'ai connu en DBE\Paradox ou un en DBase qui ont eu besoin d'un accès concurrentiel plus performant sont passés sur MySQL ou FireBird ...

Conclusion pour le couple BDE\Paradox
TQuery pour le quotidien a très faible volume (idéalement, la ligne ou de petite liste)
TTable pour les traitements en masse où beaucoup de données sont échangées entre le module et le BDE

[freud]

TTable pour les traitements en masse où beaucoup de données sont échangées entre le module et le BDE

Ca fait l'affaire surtout dans le contexte actuel où je n'ai qu'une seule option de traitement à modifier et qui, justement, fait du traitement en masse pour le reste ce n'est que des queries. Il me semblait que Refresh faisait du close/open mais puisque tu le dis....

Tu passais tes fichiers sur un serveur UNIX via un Samba, tu pouvais monter à 100 !

Ca montait 100 à cause de quoi précisément ?

Merci ShaiLeTroll

[freud]

Ah non pardon, j'etait obligé de faire du close/open à cause du Table.LockTable(ltWriteLock) où des tables etaient impliquées dans certains traitements.
Pour ce qui est du flushbuffers, j'utilise à la place le BDEFLUSHBUFFERS de la JVCL car comme il y avait plusieurs tables a flusher donc une seule ligne me suffisait pour eviter des tracas au cas où j'aurais oublier un flushbuffers.

[anapurna]

Le avantageusement n'est pas de circonstance. Un for sera toujours plus rapide qu'un while car la condition d'arret est évaluée une seul fois au démarrage de la boucle, alors que le while l'évalue à chaque itération.
Par contre, il faut utiliser un break pour en sortir sur un condition spéciale (je n'en suis pas fan non plus, mais je l'utilise avec parcimonie, en le mettant en exergue avec un code du genre
break; //------------- BREAK ---------------)

quand je parle avantageusement c'est pour la possibilité d'avoir d'autre option de sortie
le for ne fait qu'une boucle incrémentale
la condition de sortie n'est pas fait seulement au debut
a chaque boucle on teste si on est sur le dernier incrément ou pas mais c'est effectivement plus rapide que deux test
quand au break cela oblige le compilateur a savoir sur quel item ils se trouve du coup tu perd l'avantage d'une sortie "classique"

je me souvient d'un test qu'un apprenti ingé avais fait entre un boucle dites classique et des boucles a base de for break exit continue ...
au final il a eu quelque surprise ... depuis les compilateur on peut être évolué mais rien n'est moins sure

Comme le dit Sergio, je crois qu'il faudrait revoir ta query qui est peut être mal ficelée. Il me semble qu'une grosse requete sera plus efficace qu'une boucle qui effectue plein de petites requetes.

Autrement, dans l'IDE, options du projet > compilateur > optimisation te permet d'optimiser aussi les boucles quand c'est possible (boucle a l'envers car la comparaison à 0 est une instruction processeur directe par exemple)

sauf que si tu fait un break cela m’étonne que le compilo l'optimise

[ShaiLeTroll]

Ca montait 100 à cause de quoi précisément ?

100 utilisateurs en accès concurrentiel, quelques choses de modérer, beaucoup d'utilisateurs en consultation et quelques un en écriture
Dès que tu as un client qui écrit beaucoup, cela fout la merde !

[guillemouze]

quand au break cela oblige le compilateur a savoir sur quel item ils se trouve du coup tu perd l'avantage d'une sortie "classique"

sauf que si tu fait un break cela m’étonne que le compilo l'optimise

pour l'optimisation, je suis d'accord, je pense qu'au niveau des boucles, l'optimisation doit etre assez rare et se limiter à des cas simples (c'était surtout pour préciser que l'option existe).
pour le break, je suis pas un spécialiste de l'asm, mais je crois que dans tous les cas, quand tu arrive a ta condition d'arret, il y a un jmp vers l'instruction juste apres ta boucle, donc le break doit faire exactement la meme instruction (un goto finBoucle quoi)

[freud]

Bonjour,
Désolé pour le retour tardif.

100 utilisateurs en accès concurrentiel, quelques choses de modérer, beaucoup d'utilisateurs en consultation et quelques un en écriture
Dès que tu as un client qui écrit beaucoup, cela fout la merde !

Merci ShaiLeTroll.
Existe-t-il une petite solution d'acces à distance aux tables pdx genre par exemple TeamViewer ?
Merci.