|
FORUMS PROFESSIONNELS WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
[WM9 PreVersion] Comment accelerer l'acces aux contacts ? |
Débuté par metsdumanche, 15 déc. 2004 19:49 - 17 réponses |
| |
| | | |
|
| |
Posté le 15 décembre 2004 - 19:49 |
Bonjour,
Comment peut-on optimiser l'accès à la base de données de contacts ? Par exemple, pour lire mes 250 contacts dans une boucle sur mon SPV M2000 (Qtek 9090), il faut 4 secondes, alors que d'autres programmes écrits en C++ n'en demandent qu'une ! Y a-t-il un autre moyen de parcourir les contacts ?
Merci.
-- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 15 décembre 2004 - 22:36 |
Pour avoir déjà fait quelques recherches sur ce sujet (chtiContact), j'ai pu constater que bien souvent, ce sont les calculs ou actions que l'on fait pour chaque enregistrement qui prennent du temps (stockage en variable, formatage du texte, etc) comparativement au temps que prennent les fonctions de parcours dans le carnet d'adresses (cdb...) Essaye dans un premier temps de ne rien faire si ce n'est parcourir la base des contact pour voir le temps que prend le parcours à vide...
"Jean-Michel CAMBOT" <metsdumanche@baliciel.virer.com> a écrit dans le message de news:41c07021$1@news.pcsoft.fr...
Bonjour, Comment peut-on optimiser l'accès à la base de données de contacts ? Par exemple, pour lire mes 250 contacts dans une boucle sur mon SPV M2000 (Qtek 9090), il faut 4 secondes, alors que d'autres programmes écrits en C++ n'en demandent qu'une ! Y a-t-il un autre moyen de parcourir les contacts ? Merci. -- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 00:49 |
"Lionel Pratz" a écrit :
Pour avoir déjà fait quelques recherches sur ce sujet (chtiContact), j'ai pu constater que bien souvent, ce sont les calculs ou actions que l'on fait pour chaque enregistrement qui prennent du temps (stockage en variable, formatage du texte, etc) comparativement au temps que prennent les fonctions de parcours dans le carnet d'adresses (cdb...) Essaye dans un premier temps de ne rien faire si ce n'est parcourir la base des contact pour voir le temps que prend le parcours à vide...
Tu as raison ! Contrairement à la version PC où le programme consomme beaucoup de temps à ranger le résultat d'une requête dans les variables, là j'ai pu mesurer le temps passé dans les traitements "annexes". Si je lis juste les 250 contacts, et range les champs dans des variables (ou pas), cela prend 2 secondes (tout de même . Si je construis en plus des chaînes en concaténant les infos des différents champs, ça ne change pas (2 secondes). Par contre, si j'ajoute une ligne dans une table pour chaque contact, cela prend 2 secondes de plus (ça double le temps).
Donc c'est le fait d'ajouter une ligne à une table qui prend du temps
Sur les 9 colonnes texte, il n'y a que la première de visible ! Les autres sont masquées (non visibles). Si je les rend visibles, le temps passe à 8 secondes (doublé) ! Donc il passe du temps à afficher une table de 250 lignes avec une seule colonne de 30 caractères environ, sachant que seulement une dizaine de lignes sont visibles à l'écran ....
Je n'ai aucun moyen d'éviter ça ! Il faut bien que j'affiche ma liste de contacts ... Quoi utiliser sinon une table ?
Avec Delphi, il y avait un moyen de désactiver l'affichage d'un Grid (sorte de super table) pendant le remplissage, afin de ne travailler qu'en mémoire pendant le remplissage. Une fois remplie, on réaffiche la table d'un coup. Y'a pas un système comme ça avec WinDev ?
Merci.
P.S. : Le WebMaster de PocketPC France (www.pocketpcfrance.info) avait l'air emballé par l'idée de participer à la création d'un consortium de développeurs français sur Pocket PC ...
-- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 01:08 |
En mettant la propriété "Visible" de la table à Faux pendant le remplissage, je gagne 1 seconde 1/2 ...
-- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 09:59 |
Bien vu
"Jean-Michel CAMBOT" <metsdumanche@baliciel.virer.com> a écrit dans le message de news:41c0bae1$1@news.pcsoft.fr...
En mettant la propriété "Visible" de la table à Faux pendant le remplissage, je gagne 1 seconde 1/2 ... -- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 10:40 |
Je pense que la solution pour Windev dans le pocket PC et de resoudre le probleme de l'affichage sur la table pour des bases de donnees importantes. Est-ce qu'un tableau dynamique ne pourrait pas faire l'affaire. Le grid semble interessant sur le pocket PC, il faut absolument contourner le remplissage de la table mettre en memoire le resultat.
En creant avec memcree une zone memoire ne serait-ce pas une solution puis mettre le resultat mis en memoire dans cette zone dans une table, on pourrait avoir le meme resultat peut-etre qu'avec un grid. Je vais commence a faire des experience avec les zones memoires. Cela fait longtemps que je ne les plus utilises. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 10:45 |
En faisant sur Windev le test de performance je n'ai trouve aucune difference avec Visible vrai et faux pour la table. L'analyseur de performance est formelle le temps perdu c'est hlitpremier et tableajouteligne. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 11:17 |
On cree une zone memoire avec MemCree("ZONE"), au lieu de faire un tableajouteligne on fait un Memajoute("ZONE",ID) avec seulement l'ID numerique. Cette zone memoire est remplie donc seulement par quelques elements des resultats, faire ensuite un tableajouteligne en utilisant l'ID numerique des quelques elements de la zone memoire doit etre normallement instantanee. Tout le gain est de savoir si le remplissage de la zone memoire c'est a dire Memajoute est plus rapide que tableajouteligne.
Note: j'ai quand meme des doutes car s'il y avait un gain de temps d'autres dans ce newsgroup le ferait deja. Mais peut-etre que dans le Windevmobile cela peut etre utile a tester. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 11:33 |
Bonjour,
Vous pouvez accélérer un traitement en inhibant l'affichage. Vous devez pour cela utiliser la propriété de fenêtre <..AffichageActif=Faux>.
J'espère avoir pu vous orienter.
Respectueuses salutations. Jean MOREL (jeanmorel@ifrance.com) |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 11:57 |
Voila les premiers resultats de mes tests, c'est impressionnant:
Je fait un hlit premier et hlitdernier sur un fichier de 8500 lignes. Pour remplir la table memoire (visible ou pas) je mets 761 ms en utilisant tableajouteligne (8500 utilisation de tableajouteligne) avec 3 rubriques a remplir dont une seule visible. Avec Memajoute qui remplace simplement tableajouteligne je mets 49 ms pour remplir la zone memoire et sur mon analyseur de performance j'ai bien 8500 utilisation de Memajoute. C'est donc 15 x plus rapide.
Maintenant le probleme c'est de recuperer ce qui est dans la zone memoire.
J'ai fait un Memajoute(Zone, Client.IDClient, HNenreg(Client))
Donc l'astuce serait de remplir la table au fur et a mesure ou en utilisant un Thread. En traitant bien on doit etre gagnant et obtenir d'excellent resultat.
Note: je n'ai aucune idee de ce que ca donne en manipulation sur un Pocket. Mais en cas de resultat important genre 100 lignes on pourrait dire au client de lire les dix premiers enregistrement puis les 10 suivant en cliquant sur un bouton avance/recul. cela ne poserait pas de probleme car sur un pocket s'est plus simple de cliquer sur un bouton que de manipuler un ascenseur.
Je mets pour une lecture de 8500 lignes (10MB de fichier) sur mon pocket PC 1 min 30 sec. En theorie on peut se rapprocher de 6 secondes. Avec un SD ultraSpeed et un ship de 624MHZ peut-etre meme 3 secondes. On arriverait au meme resultat qu'avec un PC standard en terme de performance. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 12:37 |
L'analyseur de performance n'est pas utilisable directement sur le Pocket, et j'ai remarqué que tout n'est pas proportionnel: si sur le simulateur fonction1 met 2ms à s'éxecuter et fonction2 4ms, sur le Pocket le ratio ne sera pas forcément le même, hélas, on pourrait par exemple avoir respectivement 15 et 100ms. Je trouve donc, tout au moins pour Windev mobile, l'intérêt de l'analyseur de performance limité.
"braun" <medow@inter.net.il> a écrit dans le message de news:41c14102$1@news.pcsoft.fr...
En faisant sur Windev le test de performance je n'ai trouve aucune
difference avec Visible vrai et faux pour la table. L'analyseur de performance est formelle le temps perdu c'est hlitpremier et tableajouteligne.
|
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 12:40 |
"JM" a écrit :
Vous pouvez accélérer un traitement en inhibant l'affichage. Vous devez pour cela utiliser la propriété de fenêtre <..AffichageActif=Faux>. J'espère avoir pu vous orienter.
Je vais tester cette solution, merci. Je pense que ça doit avoir le même résultat qu'en mettant la propriété "Visible" de la table en cours de remplissage à "Faux".
-- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 14:17 |
Dans une recherche avec Hexecuterequete sur un critere, l'analyseur de performance donne pour ajoute ligne 68 ms et 33 ms pour hexecuterequete sur Windev8. Donc sur une recherche qui met 1 min 30 secondes sur pocket PC plus d'une minute pourrait correspondre au remplissage de la table. On doit pouvoir descendre en dessous des 30 secondes pour une recherche sur un fichier de 8500 lignes (10 MB) sur pocket PC standard. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 14:19 |
J'ai teste cette fonction sur Windev8 et je n'ai vu sur l'analyseur de performance aucune difference dans les temps obtenus. Tous les tests que j'ai fait avec l'analyseur de performance n'ont montre aucune difference de temps meme avec une table invisible. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 15:41 |
Dernier resultat:
En utilisant la zone memoire on arrive a des temps de 2 ms pour remplissage de la table (au lieu de 130 ms pour l'ensemble du resultat plus de 100) pour la partie visible 10 lignes, chaque clique sur l'ascenseur remplace les 10 lignes par les 10 suivantes (simulation d'un defile). Hnbrenregi est supprime au memocurrence qui prend quelques ms au lieu de 700 ms.
Tout cela doit maintenant etre teste sur le pocket pour confirmation d'un reel progres des performances. Un autre avantage de la zone memo (qui est tres legere) c'est qu'avant d'afficher quoi que ce soit, je peux faire un hannuledeclaration de ma requete ce qui libere le maximum de memoire sur mon pocket avant l'affichage sur la table (ce qui n'est pas le cas sans on utilisation).
Tout cela n'est valable que pour le pocket pc; car le gain de temps est minime relativement mettre 1/4 second au lieu de 2 secondes sur Windev8 au prejudice d'une facilite d'utilisation de la table n'a pas un grand interet. Mais passer de 1 min 30 secondes a 20 secondes sur le pocket PC ce serait une enorme difference de performance. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 16:22 |
Derniers resultats sur l'analyseur de performance sont vraiment incroyable (autant qu'on puisse extrapoller ces resultats sur le Pocket PC, soyons prudents):
Pour le meme resultat d'affichage sur la partie visible de la table 10 lignes:
Pour l'utilisation d'une facon standard de la requete avec ajoute ligne sur un resultat de plus de 100 toujours sur Windev8 (tous les tests sont destines a une utilisation sur Pocket PC), j'obtiens:
HExecuteRequete2 ms Tableajouteligne!9 ms Hlitsuivante8 ms
Total = 909 ms
---------------------------------- En utilisant la zone memo:
HexecuteRequte2 ms Tableajouteligne=4 ms Hlitsuivant=1 ms total7 ms
Presque 30 x plus rapide: si cela se confirme sur le pocket, c'est vraiment interessant.
Chaque clic pour le remplissage des 10 lignes suivantes prend 5 ms toute a ete libere et on ne travaille plus que sur un index numerique (maximum de performance). Par consequent meme si le pocket PC est 100 x plus lent on doit afficher la table pour les suivants en moins de 1/2 seconde et peut-etre meme moins avec un thread c'est transparent qui prepare l'affichage suivant.
Conclusion: Dans ces nouvelles conditions seul le HexecuteRequete est long si quelqu'un a une idee du meilleur code possible pour le pocket dans l'utilisation d'un thread dans ce cas qu'il me fasse part de son idee. La version 9 apporte-t-elle un changement sur le HexecuteRequete (je ne l'ai pas encore teste). |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 16:23 |
"braun" a écrit :
Tout cela doit maintenant etre teste sur le pocket pour confirmation d'un reel progres des performances.
Absolument. En fait, le comportement et les performances n'ont aucun rapport entre la version PC et la version PPC. Sur un Pocket PC, l'affichage est vachement lent, même pour les meilleurs, comparé à l'affichage d'un PC. Dans mon cas, ce n'est pas le remplissage de la table en soi qui prends du temps, mais l'affichage qu'il doit faire après ajout de chaque ligne, même celles en dehors de la zone visible ! Car en désactivant l'affichage de la table pendant le remplissage, on gagne beaucoup de temps.
Sur PC, j'ai divisé par 4 ou 5 les temps d'exécution de certains traitements, simplement en ne lisant les variables d'une ligne retournée par une requête qu'une fois (en les rangeant dans des variables locales), puis en manipulant ces variables locales à la place des MaRequête.xxxxx.
Sur Pocket PC, avec la base de données de contacts, cela n'a aucune incidence.
Sur Pocket PC, globalement, on peut dire que les applications WinDev Mobile (8 ou 9) sont particulièrement lentes en affichage. Mais comme on a tendance à charger assez facilement les écrans, car c'est si facile, ceci explique sans doute cela (en partie).
-- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | |
| |
Posté le 16 décembre 2004 - 17:01 |
Tout à fait, j'avais déja signalé ces lenteurs d'affichage en juillet 2004 ici-même lors de la sortie de windev8. Il serait excellent de pouvoir avoir un analyseur de performance interne au pocketpc pour trouver précisément les fonctions consommatrices en temps processeur...
"Jean-Michel CAMBOT" <metsdumanche@baliciel.virer.com> a écrit dans le message de news:41c1914c$1@news.pcsoft.fr...
"braun" a écrit : Tout cela doit maintenant etre teste sur le pocket pour confirmation d'un reel progres des performances.
Absolument. En fait, le comportement et les performances n'ont aucun rapport entre la version PC et la version PPC. Sur un Pocket PC, l'affichage est vachement lent, même pour les meilleurs, comparé à l'affichage d'un PC. Dans mon cas, ce n'est pas le remplissage de la table en soi qui prends du temps, mais l'affichage qu'il doit faire après ajout de chaque ligne, même celles en dehors de la zone visible ! Car en désactivant l'affichage de la table pendant le remplissage, on gagne beaucoup de temps. Sur PC, j'ai divisé par 4 ou 5 les temps d'exécution de certains traitements, simplement en ne lisant les variables d'une ligne retournée par une requête qu'une fois (en les rangeant dans des variables locales), puis en manipulant ces variables locales à la place des MaRequête.xxxxx. Sur Pocket PC, avec la base de données de contacts, cela n'a aucune incidence. Sur Pocket PC, globalement, on peut dire que les applications WinDev Mobile (8 ou 9) sont particulièrement lentes en affichage. Mais comme on a tendance à charger assez facilement les écrans, car c'est si facile, ceci explique sans doute cela (en partie). -- Jean-Michel CAMBOT metsdumanche chez baliciel.com Baliciel HomePage : http://www.baliciel.com/ |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|