Discussion :

[tarek_ep]

Bonjour;
J'ai une aplication développez avec delphi 7 en utilisant les composant fibplus,
a l'execution d'une requette sur une table qui contient 4402 enregistrement elle reste 2 à 3 s mais avec EMS Sql manager il execute dans 0.02 s je ne sait pas pourquoi cette défirence de vitesse?
Je trouve que m'application est très lente comment augmenter sa rapidité?

[SergioMaster]

bonjour ,
pour le point 1 une suggestion :
ta requête récupère peut-être tous les enregistrements de la table contrairement à EMSSQLManager.

Ton application est très lente , poses toi les questions suivantes
- trop d'informations inutiles (i.e. SELECT * au lieu d'un SELECT A,B,C FROM ...)
- Ouverture de toute la table pour la modification d'un enregistrement
(i.e. select * from table au lieu de select * from table where cle='xxx')
c'est fou ce que j'ai pu améliorer la vitesse d'exécution rien qu'en utilisant ces 2 questions
- dans le cas d'un dbgrid récupération d'une ensemble réduit d'enregistrement pas de toute la table
- utilisation de recordcount (toujours lent)
- bonnes Indexation de la BDD (vérifer les plans de requête)
- problèmes réseaux

[Just-Soft]

Salut;

2 à 3 sec pour 4402 enregistrements ! Je voudrais bien voir cette requête. Sauf si elle fait des calculs conditionnés.

[tarek_ep]

j'utilise cette requette:
SELECT Code_P, Design_P, Unite_P, Code_FM FROM ARTICLE
dans pfibDataset

[SergioMaster]

effectivement , c'est on ne peu plus court
Maintenant comme le dit Just-Soft , y aurait-il un évènement / calcul quelconque sur chaque enregistrement au niveau de ton programme ?

[Edit]
Comment accèdes-tu à la BDD (chaine de connexion), mode de transaction

[Just-Soft]

j'utilise cette requette:
SELECT Code_P, Design_P, Unite_P, Code_FM FROM ARTICLE
dans pfibDataset

comme y a rien de particulier dans ta requête alors va falloir voir ton mode de connexion à la BDD. Autrement dit, lors d'un second appel de ta requête est-elle aussi lente à répondre ou met-elle moins de temps que le premier accès ?

[philnext]

mmm..je pense que ce n'est lié ni à la requète ni à la connexion (au vu des éléments fournis) mais peut être que ta requète 'approvisionne' un composant style un DBGRID ou autre.
Je te conseille plutot de vérifier avec un profiler :
http://www.prodelphi.de/

[Just-Soft]

mmm..je pense que ce n'est lié ni à la requète ni à la connexion (au vu des éléments fournis) mais peut être que ta requète 'approvisionne' un composant style un DBGRID ou autre.
Je te conseille plutot de vérifier avec un profiler :
http://www.prodelphi.de/

+1

Faudrait le tester et l'approuver !

[Franck SORIANO]

l'execution d'une requette sur une table qui contient 4402 enregistrement elle reste 2 à 3 s mais avec EMS Sql manager il execute dans 0.02 s je ne sait pas pourquoi cette défirence de vitesse?

Ca ne me surprend pas tant que ça.
Je ne serais pas étonné que EMS Sql manager se contente d'ouvrir un curseur sur la table sans charger toutes les données (20 ms pour charger 4402 enregistrements c'est vraiment très court, même en ayant les données en cache dans le SGBD et en travaillant en local) alors que dans ton appli, l'ouverture de la table doit provoquer son chargement complet en mémoire.

Ce n'est pas le temps d'exécution de la requête qui doit être important mais le temps de lecture des données.

Pour améliorer les perfs, SergioMaster t'a déjà donné la méthode :
- Il faut réduire le volume des informations retournées (en limitant les champs demandés dans le SELECT, avec des filtres appropriés, en évitant d'exécuter 50 fois la même requête pour rien...).
- Il faut vérifier les plans d'exécution des requêtes : s'assurer qu'il y a bien les bons indexes aux bons endroits...

Selon les requêtes tu auras le meilleur gain en jouant sur l'un ou l'autre. C'est pour ça qu'il est très important d'avoir un moyen de tracer précisément l'exécution des requêtes, en identifiant le temps d'exécution de la requête sur le serveur (le temps avant que ce dernier ne rende la main et fournisse le curseur de lecture des résultats) et le temps de fetch des données.