J'ai un petit problème de perf sur une table fichier toute simple:
Je remplit une table fichier contenant 1 seule colonne à partir d'un fichier
contenant environ 40.000 enregistrements;
Le fichier lié est une requête déclarée dans l'éditeur du type "SELECT
DISTINCT X FROM FICHIER", la colonne X étant bien déclarée comme clé (avec
doublons) dans le fichier. Rien de très compliqué, pas de jointure, ...
Mais voila la première fois que je lance le prog il met environ 30" avant
d'afficher la table ! Soit pratiquement + lent ou pas différent de
l'utilisation d'une table mémoire. C'est la que je ne comprends pas,
normalement l'utilisation des tables fichiers doit rendre l'affichage
instantanée, pagination aidant. Ce qui visiblement n'est pas le cas.
J'ai aussi essayé en désactivant les bulles, l'ascenseur, les filtres mais
cela ne change rien.
Quelqu'un aurait-il une idée ? Parce que le jour au je passes à 200.000
enreg et + ... bonjour le massacre :)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
mat
Steph wrote:
Bonsoir,
J'ai un petit problème de perf sur une table fichier toute simple:
Je remplit une table fichier contenant 1 seule colonne à partir d'un fichier contenant environ 40.000 enregistrements;
Le fichier lié est une requête déclarée dans l'éditeur du type "SELECT DISTINCT X FROM FICHIER", la colonne X étant bien déclarée comme clé (avec doublons) dans le fichier. Rien de très compliqué, pas de jointure, ...
Mais voila la première fois que je lance le prog il met environ 30" avant d'afficher la table ! Soit pratiquement + lent ou pas différent de l'utilisation d'une table mémoire. C'est la que je ne comprends pas, normalement l'utilisation des tables fichiers doit rendre l'affichage instantanée, pagination aidant. Ce qui visiblement n'est pas le cas.
J'ai aussi essayé en désactivant les bulles, l'ascenseur, les filtres mais cela ne change rien.
Quelqu'un aurait-il une idée ? Parce que le jour au je passes à 200.000 enreg et + ... bonjour le massacre :)
Merci.
Bonjour Steph,
Si tu fais une recherche sur les divers forums sur "lenteur" ou requête, tu vas vite voir que tu n'est pas le premier à remarquer cela. Quelques explications se trouvent dans le fil de mon post du 21.9., [WD 7.5 / 8.0] Requêtes sur Hyperfile et lenteurs réseau.
La raison principale c'est que les requêtes Windev/HF ne sont vraisemblablement pas de requêtes classiques. Ci-bas des recommendations pour l'usage de requêtes comme alimentation de tables fichiers que j'ai donné récemment sur la ML Windev-Forum.
Salutations Mat
Post dans la ML Windev-Forum du 21.10.
Michel wrote: > > Devant des performances lamentable sur l'affichage d'une table à partir d'une requète sur 3 tables HF, j'ai lancé l'analyseur de performance. > > 19 secondes pour la seule fonction HLitPremier. > > > J'ai donc isolé le code et fait des tests > > La requète retourne 147 enregistrements d'une vingtaine de champ environ. > Le code de cette requete est reconnue optimisée sous l'editeur de requète (tous les index sont donc présents). > L'execution de HExecuteRequeteSQL met entre 2 et 3 secondes (+- dèja énorme vu le nombre d'enregistrements retournés, présence d'une sous requete censée accelerer le traitement) > > Par contre la seule instruction HLitPremier prends entre 14 et 17 secondes ????? > > L'utilisation de HOptimiseRequete n'a aucune influence. > > Quelqu'un aurait une piste pour améliorer ce temps de traitement ?
La requête prend toujours les 14 à 17 secondes mais normalement se termine en arrière plan. Elle ne peut pas faire cela dans des cas comme le tri de la requête (ORDER BY), surtout lorsqu'on trie sur des rubriques venant de fichiers différents, calcul de totaux ou tentative de lecture d'un enregistrement pas encore lu en mémoire (comme p.ex. HLitDernier).
La raison pour cela est que HF lit en mémoire tout le résultat de la requête, tandis que d'autres BD ne lisent en mémoire que les enregistrements affichés. Le seul avantage de ce comportement de HF que j'ai pu décerner est que le passage du résultat, un fois lu en mémoire, est extrèmement rapide ce qui facilite des calculs sur la totalité du résultat. Autrement, je n'ai trouvé que des désavantages.
Il y a plusieurs possibilités d'améliorer la vitesse:
- éviter des relations de fichiers par WHERE en faveur de JOIN - critères de sélection par WHERE appliqués seulement au fichier principale des données; sur les autres, utiliser des sous-requêtes ...IN (SELECT ..., c'est bcp plus efficace, - réduire au maximum le nombre de fichiers de la requête lorsqu'il risque d'avoir un grand nombre de résultats. Favoriser, idiot que cela peut paraître, HLitRecherche dans l'affichage de la table pour obtenir des valeurs d'autres fichiers sur lesquels il ne faut pas trier.
Steph wrote:
Bonsoir,
J'ai un petit problème de perf sur une table fichier toute simple:
Je remplit une table fichier contenant 1 seule colonne à partir d'un fichier
contenant environ 40.000 enregistrements;
Le fichier lié est une requête déclarée dans l'éditeur du type "SELECT
DISTINCT X FROM FICHIER", la colonne X étant bien déclarée comme clé (avec
doublons) dans le fichier. Rien de très compliqué, pas de jointure, ...
Mais voila la première fois que je lance le prog il met environ 30" avant
d'afficher la table ! Soit pratiquement + lent ou pas différent de
l'utilisation d'une table mémoire. C'est la que je ne comprends pas,
normalement l'utilisation des tables fichiers doit rendre l'affichage
instantanée, pagination aidant. Ce qui visiblement n'est pas le cas.
J'ai aussi essayé en désactivant les bulles, l'ascenseur, les filtres mais
cela ne change rien.
Quelqu'un aurait-il une idée ? Parce que le jour au je passes à 200.000
enreg et + ... bonjour le massacre :)
Merci.
Bonjour Steph,
Si tu fais une recherche sur les divers forums sur "lenteur" ou requête,
tu vas vite voir que tu n'est pas le premier à remarquer cela. Quelques
explications se trouvent dans le fil de mon post du 21.9., [WD 7.5 /
8.0] Requêtes sur Hyperfile et lenteurs réseau.
La raison principale c'est que les requêtes Windev/HF ne sont
vraisemblablement pas de requêtes classiques. Ci-bas des recommendations
pour l'usage de requêtes comme alimentation de tables fichiers que j'ai
donné récemment sur la ML Windev-Forum.
Salutations
Mat
Post dans la ML Windev-Forum du 21.10.
Michel wrote:
>
> Devant des performances lamentable sur l'affichage d'une table à
partir d'une requète sur 3 tables HF, j'ai lancé l'analyseur de performance.
>
> 19 secondes pour la seule fonction HLitPremier.
>
>
> J'ai donc isolé le code et fait des tests
>
> La requète retourne 147 enregistrements d'une vingtaine de champ environ.
> Le code de cette requete est reconnue optimisée sous l'editeur de
requète (tous les index sont donc présents).
> L'execution de HExecuteRequeteSQL met entre 2 et 3 secondes (+- dèja
énorme vu le nombre d'enregistrements retournés, présence d'une sous
requete censée accelerer le traitement)
>
> Par contre la seule instruction HLitPremier prends entre 14 et 17
secondes ?????
>
> L'utilisation de HOptimiseRequete n'a aucune influence.
>
> Quelqu'un aurait une piste pour améliorer ce temps de traitement ?
La requête prend toujours les 14 à 17 secondes mais normalement se
termine en arrière plan. Elle ne peut pas faire cela dans des cas comme
le tri de la requête (ORDER BY), surtout lorsqu'on trie sur des
rubriques venant de fichiers différents, calcul de totaux ou tentative
de lecture d'un enregistrement pas encore lu en mémoire (comme p.ex.
HLitDernier).
La raison pour cela est que HF lit en mémoire tout le résultat de la
requête, tandis que d'autres BD ne lisent en mémoire que les
enregistrements affichés. Le seul avantage de ce comportement de HF que
j'ai pu décerner est que le passage du résultat, un fois lu en mémoire,
est extrèmement rapide ce qui facilite des calculs sur la totalité du
résultat. Autrement, je n'ai trouvé que des désavantages.
Il y a plusieurs possibilités d'améliorer la vitesse:
- éviter des relations de fichiers par WHERE en faveur de JOIN
- critères de sélection par WHERE appliqués seulement au fichier
principale des données; sur les autres, utiliser des sous-requêtes
...IN (SELECT ..., c'est bcp plus efficace,
- réduire au maximum le nombre de fichiers de la requête lorsqu'il
risque d'avoir un grand nombre de résultats. Favoriser, idiot que cela
peut paraître, HLitRecherche dans l'affichage de la table pour obtenir
des valeurs d'autres fichiers sur lesquels il ne faut pas trier.
J'ai un petit problème de perf sur une table fichier toute simple:
Je remplit une table fichier contenant 1 seule colonne à partir d'un fichier contenant environ 40.000 enregistrements;
Le fichier lié est une requête déclarée dans l'éditeur du type "SELECT DISTINCT X FROM FICHIER", la colonne X étant bien déclarée comme clé (avec doublons) dans le fichier. Rien de très compliqué, pas de jointure, ...
Mais voila la première fois que je lance le prog il met environ 30" avant d'afficher la table ! Soit pratiquement + lent ou pas différent de l'utilisation d'une table mémoire. C'est la que je ne comprends pas, normalement l'utilisation des tables fichiers doit rendre l'affichage instantanée, pagination aidant. Ce qui visiblement n'est pas le cas.
J'ai aussi essayé en désactivant les bulles, l'ascenseur, les filtres mais cela ne change rien.
Quelqu'un aurait-il une idée ? Parce que le jour au je passes à 200.000 enreg et + ... bonjour le massacre :)
Merci.
Bonjour Steph,
Si tu fais une recherche sur les divers forums sur "lenteur" ou requête, tu vas vite voir que tu n'est pas le premier à remarquer cela. Quelques explications se trouvent dans le fil de mon post du 21.9., [WD 7.5 / 8.0] Requêtes sur Hyperfile et lenteurs réseau.
La raison principale c'est que les requêtes Windev/HF ne sont vraisemblablement pas de requêtes classiques. Ci-bas des recommendations pour l'usage de requêtes comme alimentation de tables fichiers que j'ai donné récemment sur la ML Windev-Forum.
Salutations Mat
Post dans la ML Windev-Forum du 21.10.
Michel wrote: > > Devant des performances lamentable sur l'affichage d'une table à partir d'une requète sur 3 tables HF, j'ai lancé l'analyseur de performance. > > 19 secondes pour la seule fonction HLitPremier. > > > J'ai donc isolé le code et fait des tests > > La requète retourne 147 enregistrements d'une vingtaine de champ environ. > Le code de cette requete est reconnue optimisée sous l'editeur de requète (tous les index sont donc présents). > L'execution de HExecuteRequeteSQL met entre 2 et 3 secondes (+- dèja énorme vu le nombre d'enregistrements retournés, présence d'une sous requete censée accelerer le traitement) > > Par contre la seule instruction HLitPremier prends entre 14 et 17 secondes ????? > > L'utilisation de HOptimiseRequete n'a aucune influence. > > Quelqu'un aurait une piste pour améliorer ce temps de traitement ?
La requête prend toujours les 14 à 17 secondes mais normalement se termine en arrière plan. Elle ne peut pas faire cela dans des cas comme le tri de la requête (ORDER BY), surtout lorsqu'on trie sur des rubriques venant de fichiers différents, calcul de totaux ou tentative de lecture d'un enregistrement pas encore lu en mémoire (comme p.ex. HLitDernier).
La raison pour cela est que HF lit en mémoire tout le résultat de la requête, tandis que d'autres BD ne lisent en mémoire que les enregistrements affichés. Le seul avantage de ce comportement de HF que j'ai pu décerner est que le passage du résultat, un fois lu en mémoire, est extrèmement rapide ce qui facilite des calculs sur la totalité du résultat. Autrement, je n'ai trouvé que des désavantages.
Il y a plusieurs possibilités d'améliorer la vitesse:
- éviter des relations de fichiers par WHERE en faveur de JOIN - critères de sélection par WHERE appliqués seulement au fichier principale des données; sur les autres, utiliser des sous-requêtes ...IN (SELECT ..., c'est bcp plus efficace, - réduire au maximum le nombre de fichiers de la requête lorsqu'il risque d'avoir un grand nombre de résultats. Favoriser, idiot que cela peut paraître, HLitRecherche dans l'affichage de la table pour obtenir des valeurs d'autres fichiers sur lesquels il ne faut pas trier.
mat
Autre idée si tu travailles avec un nombre important d'enregistrements: appliquer un filtre au fichier affiché à travers HFiltre. Si tu ne veux pas filtrer le fichier même, utilise une 2e instance du fichier avec HAlias, HChangeNom (voir l'aide en ligne), c'est très efficace.
Autre idée si tu travailles avec un nombre important d'enregistrements:
appliquer un filtre au fichier affiché à travers HFiltre. Si tu ne veux
pas filtrer le fichier même, utilise une 2e instance du fichier avec
HAlias, HChangeNom (voir l'aide en ligne), c'est très efficace.
Autre idée si tu travailles avec un nombre important d'enregistrements: appliquer un filtre au fichier affiché à travers HFiltre. Si tu ne veux pas filtrer le fichier même, utilise une 2e instance du fichier avec HAlias, HChangeNom (voir l'aide en ligne), c'est très efficace.
Steph
> Bonjour Steph,
Si tu fais une recherche sur les divers forums sur "lenteur" ou requête, tu vas vite voir que tu n'est pas le premier à remarquer cela. Quelques explications se trouvent dans le fil de mon post du 21.9., [WD 7.5 / 8.0] Requêtes sur Hyperfile et lenteurs réseau.
La raison principale c'est que les requêtes Windev/HF ne sont vraisemblablement pas de requêtes classiques. Ci-bas des recommendations pour l'usage de requêtes comme alimentation de tables fichiers que j'ai donné récemment sur la ML Windev-Forum.
Salutations Mat
Merci
> Bonjour Steph,
Si tu fais une recherche sur les divers forums sur "lenteur" ou requête,
tu vas vite voir que tu n'est pas le premier à remarquer cela. Quelques
explications se trouvent dans le fil de mon post du 21.9., [WD 7.5 /
8.0] Requêtes sur Hyperfile et lenteurs réseau.
La raison principale c'est que les requêtes Windev/HF ne sont
vraisemblablement pas de requêtes classiques. Ci-bas des recommendations
pour l'usage de requêtes comme alimentation de tables fichiers que j'ai
donné récemment sur la ML Windev-Forum.
Si tu fais une recherche sur les divers forums sur "lenteur" ou requête, tu vas vite voir que tu n'est pas le premier à remarquer cela. Quelques explications se trouvent dans le fil de mon post du 21.9., [WD 7.5 / 8.0] Requêtes sur Hyperfile et lenteurs réseau.
La raison principale c'est que les requêtes Windev/HF ne sont vraisemblablement pas de requêtes classiques. Ci-bas des recommendations pour l'usage de requêtes comme alimentation de tables fichiers que j'ai donné récemment sur la ML Windev-Forum.
