Lenteur remplissage de table (62000 enregistrements)
31 réponses
Dams
Bonjour,
je rencontre une lenteur =E9norme lors du remplissage de ma table
(environ 32 secondes) qui contient des clients, rien de plus
classique.
Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma
table par programmation. Au dessus de ma table il y a des Onglets
alphab=E9tiques permettant =E0 l'utilisateur de filtrer les clients (A, B,
C, D ...) chaque onglet contient une lettre donc je construit mon
filtre en fonction de l'onglet s=E9lectionn=E9.
PROCEDURE RefreshClients()
// Je vide la table
TableSupprimeTout(TABLE_CLIENTS)
// Je r=E9cup=E8re la lettre s=E9lectionn=E9e dans l'onglet s=E9lectionn=E9
sLettre est une chaine =3D ONG_FILTRE[ONG_FILTRE]..Libell=E9
// Je cr=E9=E9 mon filtre sur les clients contenant la lettre s=E9lectionn=
=E9e
// sRubParcours contiendra la rubrique retourn=E9e automatiquement pour
la parcours
sRubParcours est une chaine =3D HFiltre(CLIENTS, "NOM LIKE '"+sLettre
+"%'")
// Je lit le premier client trouv=E9
HLitPremier(CLIENTS, sRubParcours)
// Je boucle sur tous les clients et je rempli ma table
TANTQUE HTrouve(CLIENTS)
TableAjouteLigne(TABLE_CLIENTS, CLIENTS.NOM, CLIENTS.PRENOM,
CLIENTS.SOCIETE)
HLitSuivant(CLIENTS)
FIN
// Je d=E9sactive le filtre cr=E9=E9
HD=E9sactiveFiltre(CLIENTS)
Le remplissage de la table dure environ 32 secondes !! Pour un simple
remplissage comme celui-ci.
Ma question est de savoir si d'apr=E8s vous je m'y prend mal pour
remplir ma table, pourtant j'utilise des filtres pour =E9viter de
charger TOUTES les donn=E9es, ou alors c'est Windev qui est limit=E9.
Le remplissage de la table dure environ 32 secondes !! Pour un simple remplissage comme celui-ci.
La rubrique CLIENT est-elle une clé ?
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Dams avait prétendu :
Bonjour,
Bonjour,
Le remplissage de la table dure environ 32 secondes !! Pour un simple
remplissage comme celui-ci.
La rubrique CLIENT est-elle une clé ?
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Le remplissage de la table dure environ 32 secondes !! Pour un simple remplissage comme celui-ci.
La rubrique CLIENT est-elle une clé ?
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Romain PETIT
Dams avait prétendu :
Bonjour,
Bonjour,
Le remplissage de la table dure environ 32 secondes !! Pour un simple remplissage comme celui-ci.
La rubrique CLIENT.NOM est-elle une clé ?
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Dams avait prétendu :
Bonjour,
Bonjour,
Le remplissage de la table dure environ 32 secondes !! Pour un simple
remplissage comme celui-ci.
La rubrique CLIENT.NOM est-elle une clé ?
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Le remplissage de la table dure environ 32 secondes !! Pour un simple remplissage comme celui-ci.
La rubrique CLIENT.NOM est-elle une clé ?
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Gilles
Dans son message précédent, Dams a écrit :
Bonjour,
je rencontre une lenteur énorme lors du remplissage de ma table (environ 32 secondes) qui contient des clients, rien de plus classique. Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma table par programmation. Au dessus de ma table il y a des Onglets alphabétiques permettant à l'utilisateur de filtrer les clients (A, B, C, D ...) chaque onglet contient une lettre donc je construit mon filtre en fonction de l'onglet sélectionné.
Ta rubrique est indexée? Tu as essayé avec une requête paramétrée? Ca fait des siècles que je n'utilise plus cette horreur de hFiltre ;)
Dans son message précédent, Dams a écrit :
Bonjour,
je rencontre une lenteur énorme lors du remplissage de ma table
(environ 32 secondes) qui contient des clients, rien de plus
classique.
Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma
table par programmation. Au dessus de ma table il y a des Onglets
alphabétiques permettant à l'utilisateur de filtrer les clients (A, B,
C, D ...) chaque onglet contient une lettre donc je construit mon
filtre en fonction de l'onglet sélectionné.
Ta rubrique est indexée?
Tu as essayé avec une requête paramétrée?
Ca fait des siècles que je n'utilise plus cette horreur de hFiltre ;)
je rencontre une lenteur énorme lors du remplissage de ma table (environ 32 secondes) qui contient des clients, rien de plus classique. Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma table par programmation. Au dessus de ma table il y a des Onglets alphabétiques permettant à l'utilisateur de filtrer les clients (A, B, C, D ...) chaque onglet contient une lettre donc je construit mon filtre en fonction de l'onglet sélectionné.
Ta rubrique est indexée? Tu as essayé avec une requête paramétrée? Ca fait des siècles que je n'utilise plus cette horreur de hFiltre ;)
Dams
Je confirme que ma rubrique CLIENTS.NOM est une clé avec doublons.
Je vais essayer une requête paramétrée et je vous retourne le résul tat des performances.
Je confirme que ma rubrique CLIENTS.NOM est une clé avec doublons.
Je vais essayer une requête paramétrée et je vous retourne le résul tat
des performances.
Je confirme que ma rubrique CLIENTS.NOM est une clé avec doublons.
Je vais essayer une requête paramétrée et je vous retourne le résul tat des performances.
Dams
J'ai essayé de remplir ma table avec une requête, mais pas de changement, si ce n'est 2 secondes par rapport à l'utilisation de HFiltre soit au final 30 secondes de chargement pour 62000 clients dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a rien changé aux performances. J'ai effectué une analyse de performance et le résultat indique quele traitement du moteur (donc Windev) a pris environ 30 secondes (fonctions HLitPremier, HLitSuivant) La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Je viens de regarder une vidéo sur le site de Windev, qui montre un exemple de chargement d'une table avec 15 milliards d'enregistrement en quelques millisecondes .... même si ça concerne la version 15 et que je suis en 14, je me demande bien comment cela est possible sachant que pour seulement 62000 de mon côté c'est inutilisable !
Si quelqu'un veut se faire du mal un pti coup : http://www.pcsoft-windev-webdev.com/videos15/tdfcom2009/base-de-donnees-hyp erfilesql-de-15-milliards-de-lignes/base-de-donnees-hyperfilesql-de-15-mill iards-de-lignes.html
J'ai essayé de remplir ma table avec une requête, mais pas de
changement, si ce n'est 2 secondes par rapport à l'utilisation de
HFiltre soit au final 30 secondes de chargement pour 62000 clients
dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a
rien changé aux performances.
J'ai effectué une analyse de performance et le résultat indique quele
traitement du moteur (donc Windev) a pris environ 30 secondes
(fonctions HLitPremier, HLitSuivant)
La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Je viens de regarder une vidéo sur le site de Windev, qui montre un
exemple de chargement d'une table avec 15 milliards d'enregistrement
en quelques millisecondes .... même si ça concerne la version 15 et
que je suis en 14, je me demande bien comment cela est possible
sachant que pour seulement 62000 de mon côté c'est inutilisable !
Si quelqu'un veut se faire du mal un pti coup :
http://www.pcsoft-windev-webdev.com/videos15/tdfcom2009/base-de-donnees-hyp erfilesql-de-15-milliards-de-lignes/base-de-donnees-hyperfilesql-de-15-mill iards-de-lignes.html
J'ai essayé de remplir ma table avec une requête, mais pas de changement, si ce n'est 2 secondes par rapport à l'utilisation de HFiltre soit au final 30 secondes de chargement pour 62000 clients dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a rien changé aux performances. J'ai effectué une analyse de performance et le résultat indique quele traitement du moteur (donc Windev) a pris environ 30 secondes (fonctions HLitPremier, HLitSuivant) La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Je viens de regarder une vidéo sur le site de Windev, qui montre un exemple de chargement d'une table avec 15 milliards d'enregistrement en quelques millisecondes .... même si ça concerne la version 15 et que je suis en 14, je me demande bien comment cela est possible sachant que pour seulement 62000 de mon côté c'est inutilisable !
Si quelqu'un veut se faire du mal un pti coup : http://www.pcsoft-windev-webdev.com/videos15/tdfcom2009/base-de-donnees-hyp erfilesql-de-15-milliards-de-lignes/base-de-donnees-hyperfilesql-de-15-mill iards-de-lignes.html
Gilles
Dams avait soumis l'idée :
J'ai essayé de remplir ma table avec une requête, mais pas de changement, si ce n'est 2 secondes par rapport à l'utilisation de HFiltre soit au final 30 secondes de chargement pour 62000 clients dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a rien changé aux performances. J'ai effectué une analyse de performance et le résultat indique quele traitement du moteur (donc Windev) a pris environ 30 secondes (fonctions HLitPremier, HLitSuivant) La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Tu peux essayer en évitant de coder : Faire une table fichier basée sur la requête, et la paramétrer pour qu'elle charge en mémoire...
Cela dit 62000 enregistrement, ca ne veut rien dire, si tu ramènes 3 mega octets par enregistrement ;)
Tes rubriques ne sont pas énormes? Tu as essayé sur un autre pc? (antivirus??)
Dams avait soumis l'idée :
J'ai essayé de remplir ma table avec une requête, mais pas de
changement, si ce n'est 2 secondes par rapport à l'utilisation de
HFiltre soit au final 30 secondes de chargement pour 62000 clients
dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a
rien changé aux performances.
J'ai effectué une analyse de performance et le résultat indique quele
traitement du moteur (donc Windev) a pris environ 30 secondes
(fonctions HLitPremier, HLitSuivant)
La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Tu peux essayer en évitant de coder :
Faire une table fichier basée sur la requête, et la paramétrer pour
qu'elle charge en mémoire...
Cela dit 62000 enregistrement, ca ne veut rien dire, si tu ramènes 3
mega octets par enregistrement ;)
Tes rubriques ne sont pas énormes?
Tu as essayé sur un autre pc? (antivirus??)
J'ai essayé de remplir ma table avec une requête, mais pas de changement, si ce n'est 2 secondes par rapport à l'utilisation de HFiltre soit au final 30 secondes de chargement pour 62000 clients dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a rien changé aux performances. J'ai effectué une analyse de performance et le résultat indique quele traitement du moteur (donc Windev) a pris environ 30 secondes (fonctions HLitPremier, HLitSuivant) La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Tu peux essayer en évitant de coder : Faire une table fichier basée sur la requête, et la paramétrer pour qu'elle charge en mémoire...
Cela dit 62000 enregistrement, ca ne veut rien dire, si tu ramènes 3 mega octets par enregistrement ;)
Tes rubriques ne sont pas énormes? Tu as essayé sur un autre pc? (antivirus??)
Dams
Salut Gilles,
initialement ma table etait en liaison sur le fichier CLIENTS (liaison mémoire justement), c'est dû à cette lenteur que j'ai rempli la table par programmation, pensant que ça serait plus "light" mais ça change rien.
J'ai executé une requête avec WDSQL sur mon fichier CLIENTS et le résultat est instantané, ce qui m'amène à penser que ce n'est pas u n problème sur mon fichier ni ma requête puisque celle-ci s'exécute rapidement.
J'ai executé la requête suivante afin de retourner tous les clients dont le nom commence par A, et il y en a 4136
SELECT * FROM CLIENTS WHERE NOM LIKE 'A%'
C'est le remplissage de la table qui prend énormément de temps, sauf que d'après le code que je vous ai fourni, je ne vois pas comment je pourrais faire plus simple, c'est le mode de chargement le plus courant je suppose.
Concernant l'autre PC, j'ai effectué un test et c'est exactement pareil, le chargement de la table est extrêmement long. Et sur le PC de développement sur lequel je travail c'est une bête de course donc j'ai ecarté le problème de performances du PC :
Windows 7 12 Go RAM Tri-Channel CPU Intel Core I7 940
2ème PC : Windows 7 4 Go RAM CPU Intel Core I7 920
Je sèche complet !
Salut Gilles,
initialement ma table etait en liaison sur le fichier CLIENTS (liaison
mémoire justement), c'est dû à cette lenteur que j'ai rempli la table
par programmation, pensant que ça serait plus "light" mais ça change
rien.
J'ai executé une requête avec WDSQL sur mon fichier CLIENTS et le
résultat est instantané, ce qui m'amène à penser que ce n'est pas u n
problème sur mon fichier ni ma requête puisque celle-ci s'exécute
rapidement.
J'ai executé la requête suivante afin de retourner tous les clients
dont le nom commence par A, et il y en a 4136
SELECT * FROM CLIENTS WHERE NOM LIKE 'A%'
C'est le remplissage de la table qui prend énormément de temps, sauf
que d'après le code que je vous ai fourni, je ne vois pas comment je
pourrais faire plus simple, c'est le mode de chargement le plus
courant je suppose.
Concernant l'autre PC, j'ai effectué un test et c'est exactement
pareil, le chargement de la table est extrêmement long. Et sur le PC
de développement sur lequel je travail c'est une bête de course donc
j'ai ecarté le problème de performances du PC :
Windows 7
12 Go RAM Tri-Channel
CPU Intel Core I7 940
2ème PC :
Windows 7
4 Go RAM
CPU Intel Core I7 920
initialement ma table etait en liaison sur le fichier CLIENTS (liaison mémoire justement), c'est dû à cette lenteur que j'ai rempli la table par programmation, pensant que ça serait plus "light" mais ça change rien.
J'ai executé une requête avec WDSQL sur mon fichier CLIENTS et le résultat est instantané, ce qui m'amène à penser que ce n'est pas u n problème sur mon fichier ni ma requête puisque celle-ci s'exécute rapidement.
J'ai executé la requête suivante afin de retourner tous les clients dont le nom commence par A, et il y en a 4136
SELECT * FROM CLIENTS WHERE NOM LIKE 'A%'
C'est le remplissage de la table qui prend énormément de temps, sauf que d'après le code que je vous ai fourni, je ne vois pas comment je pourrais faire plus simple, c'est le mode de chargement le plus courant je suppose.
Concernant l'autre PC, j'ai effectué un test et c'est exactement pareil, le chargement de la table est extrêmement long. Et sur le PC de développement sur lequel je travail c'est une bête de course donc j'ai ecarté le problème de performances du PC :
Windows 7 12 Go RAM Tri-Channel CPU Intel Core I7 940
2ème PC : Windows 7 4 Go RAM CPU Intel Core I7 920
Je sèche complet !
Eric
Le 28 février 2010 à 23:44, dans <news:, Dams nous disait :
C'est le remplissage de la table qui prend énormément de temps, sauf que d'après le code que je vous ai fourni, je ne vois pas comment je pourrais faire plus simple, c'est le mode de chargement le plus courant je suppose.
Décoche "Ascenseur proportionnel" dans le descriptif de ta table fichier, pour voir.
-- Eric
Le 28 février 2010 à 23:44, dans
<news:ddc642a8-c7d4-47c7-92c9-7561352a7089@c16g2000yqd.googlegroups.com>,
Dams nous disait :
C'est le remplissage de la table qui prend énormément de temps, sauf
que d'après le code que je vous ai fourni, je ne vois pas comment je
pourrais faire plus simple, c'est le mode de chargement le plus
courant je suppose.
Décoche "Ascenseur proportionnel" dans le descriptif de ta table
fichier, pour voir.
Le 28 février 2010 à 23:44, dans <news:, Dams nous disait :
C'est le remplissage de la table qui prend énormément de temps, sauf que d'après le code que je vous ai fourni, je ne vois pas comment je pourrais faire plus simple, c'est le mode de chargement le plus courant je suppose.
Décoche "Ascenseur proportionnel" dans le descriptif de ta table fichier, pour voir.
-- Eric
Dams
Idem, ça ne change rien.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon fichier CLIENTS instantanément. Je pense que le principe est le même puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre interne. J'ai pensé que ça pouvait venir de là, mais le temps de chargement de la table est identique à l'initialisation de ma fenêtre interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient une table, qui elle, liste des commandes. Il y en a environ 50000 et l'affichage est instantané, j'utilise exactement le même principe de chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont environ 5000 clients dans leur fichier et pour qui les performances sont très bonnes, mais à partir de 15000 ça devient inutilisable.
Idem, ça ne change rien.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon
fichier CLIENTS instantanément. Je pense que le principe est le même
puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre
interne. J'ai pensé que ça pouvait venir de là, mais le temps de
chargement de la table est identique à l'initialisation de ma fenêtre
interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient
une table, qui elle, liste des commandes. Il y en a environ 50000 et
l'affichage est instantané, j'utilise exactement le même principe de
chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont
environ 5000 clients dans leur fichier et pour qui les performances
sont très bonnes, mais à partir de 15000 ça devient inutilisable.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon fichier CLIENTS instantanément. Je pense que le principe est le même puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre interne. J'ai pensé que ça pouvait venir de là, mais le temps de chargement de la table est identique à l'initialisation de ma fenêtre interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient une table, qui elle, liste des commandes. Il y en a environ 50000 et l'affichage est instantané, j'utilise exactement le même principe de chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont environ 5000 clients dans leur fichier et pour qui les performances sont très bonnes, mais à partir de 15000 ça devient inutilisable.
le fait de mettre la table en invisible fait gagner dut temps car l'affichage des ligne est momentaenment arreter
sous windev 12 on gagne 30 % du temps de chargement
Bon dev @+
"Dams" a écrit dans le message de news: Idem, ça ne change rien.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon fichier CLIENTS instantanément. Je pense que le principe est le même puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre interne. J'ai pensé que ça pouvait venir de là, mais le temps de chargement de la table est identique à l'initialisation de ma fenêtre interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient une table, qui elle, liste des commandes. Il y en a environ 50000 et l'affichage est instantané, j'utilise exactement le même principe de chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont environ 5000 clients dans leur fichier et pour qui les performances sont très bonnes, mais à partir de 15000 ça devient inutilisable.
le fait de mettre la table en invisible fait gagner dut temps
car l'affichage des ligne est momentaenment arreter
sous windev 12 on gagne 30 % du temps de chargement
Bon dev
@+
"Dams" <damosse31@gmail.com> a écrit dans le message de
news:084d89f1-8426-46a5-86a2-3897265dd341@d27g2000yqf.googlegroups.com...
Idem, ça ne change rien.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon
fichier CLIENTS instantanément. Je pense que le principe est le même
puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre
interne. J'ai pensé que ça pouvait venir de là, mais le temps de
chargement de la table est identique à l'initialisation de ma fenêtre
interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient
une table, qui elle, liste des commandes. Il y en a environ 50000 et
l'affichage est instantané, j'utilise exactement le même principe de
chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont
environ 5000 clients dans leur fichier et pour qui les performances
sont très bonnes, mais à partir de 15000 ça devient inutilisable.
le fait de mettre la table en invisible fait gagner dut temps car l'affichage des ligne est momentaenment arreter
sous windev 12 on gagne 30 % du temps de chargement
Bon dev @+
"Dams" a écrit dans le message de news: Idem, ça ne change rien.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon fichier CLIENTS instantanément. Je pense que le principe est le même puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre interne. J'ai pensé que ça pouvait venir de là, mais le temps de chargement de la table est identique à l'initialisation de ma fenêtre interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient une table, qui elle, liste des commandes. Il y en a environ 50000 et l'affichage est instantané, j'utilise exactement le même principe de chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont environ 5000 clients dans leur fichier et pour qui les performances sont très bonnes, mais à partir de 15000 ça devient inutilisable.
