PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV Mobile 2025 → Dégradation performances inexpliquées
Dégradation performances inexpliquées
Iniciado por degnews_, 21,nov. 2005 17:36 - 2 respuestas
Publicado el 21,noviembre 2005 - 17:36
Bonjour,

Quelques petites questions concernant les performances d'une appli
développée en WD9 34J.

Je vais partir d'un exemple précis pour tenter d'être le plus intelligible
possible ;)

Prenons donc une fenêtre3 avec une table qu'on remplit avec une ligne
identique via un "pour i=1 à 100/ tableajoute / FIN" (j'en suis arrivé à
tester avec ça plutôt que le remplissage "normal" pour tenter d'isoler le
problème, qui ne vient donc apparement pas des accès fichiers ou autre,
mais plutôt du remplissage sensu stricto de la table !).

Cette fenêtre3 est lancée depuis une fenêtre2 via un bouton. Première
utilisation : no problem, la table se remplit en environ 80-100ms. On
ferme, on reclique sur le bouton, toujours 100ms. Impec
En revanche si on ferme la fenêtre2 contenant le bouton appelant la
fenêtre3, qu'on ouvre à nouveau cette fenêtre2 et qu'on exécute le bouton,
alors aïe, perte de perf d'environ 10fois (on passe à 1000-2000ms selon les
cas) pour le remplissage de la table qui est pourtant rigoureusement le
même !!

Le pocket est un Dell Axim V5 sous pocket pc2002, qui est certes moins
performant que d'autres pocket qu'on a testé (des HP par exemple sous
pocket 2003). Je n'ai plus les HP pour tester ce protocole précisément,
mais je suis assez inquiet sur ce problème de perf car on ne contrôle de
toute façon pas ce que nos clients achèteront ou ont déjà surtout (car on
peut toujours leur conseiller du matériel donné pour ceux qui n'ont pas de
pocket actuellement)...

Des idées ??? (j'ai testé par exemple avec du utilise, mais ça ne remet pas
du tout les pendules à zéro ! seule la fermeture de l'application les
remets à zéro les pendules ! :( )

Merci d'avance pour toutes pistes, si petite soit elle ;)

--
Deg
ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez
m'écrire en privé.
Publicado el 22,noviembre 2005 - 10:02
et en utilisant la propriété

...affichageactif = faux

avant ton traitement
et

...affichageactif = vrai

apres ton traitement ?!

juste une idée comme ca...!

eric l.

"Deg" <degnews_@yahoo.fr> a écrit dans le message de news:
kmpuajmwzsje.1qg48uatos8z6$.dlg@40tude.net...

Bonjour,

Quelques petites questions concernant les performances d'une appli
développée en WD9 34J.

Je vais partir d'un exemple précis pour tenter d'être le plus intelligible
possible ;)

Prenons donc une fenêtre3 avec une table qu'on remplit avec une ligne
identique via un "pour i=1 à 100/ tableajoute / FIN" (j'en suis arrivé à
tester avec ça plutôt que le remplissage "normal" pour tenter d'isoler le
problème, qui ne vient donc apparement pas des accès fichiers ou autre,
mais plutôt du remplissage sensu stricto de la table !).

Cette fenêtre3 est lancée depuis une fenêtre2 via un bouton. Première
utilisation : no problem, la table se remplit en environ 80-100ms. On
ferme, on reclique sur le bouton, toujours 100ms. Impec
En revanche si on ferme la fenêtre2 contenant le bouton appelant la
fenêtre3, qu'on ouvre à nouveau cette fenêtre2 et qu'on exécute le bouton,
alors aïe, perte de perf d'environ 10fois (on passe à 1000-2000ms selon
les
cas) pour le remplissage de la table qui est pourtant rigoureusement le
même !!

Le pocket est un Dell Axim V5 sous pocket pc2002, qui est certes moins
performant que d'autres pocket qu'on a testé (des HP par exemple sous
pocket 2003). Je n'ai plus les HP pour tester ce protocole précisément,
mais je suis assez inquiet sur ce problème de perf car on ne contrôle de
toute façon pas ce que nos clients achèteront ou ont déjà surtout (car on
peut toujours leur conseiller du matériel donné pour ceux qui n'ont pas de
pocket actuellement)...

Des idées ??? (j'ai testé par exemple avec du utilise, mais ça ne remet
pas
du tout les pendules à zéro ! seule la fermeture de l'application les
remets à zéro les pendules ! :( )

Merci d'avance pour toutes pistes, si petite soit elle ;)

--
Deg
ôter le caractère superflu avant l'arobase de mon adresse si vous
souhaitez
m'écrire en privé.
Publicado el 23,noviembre 2005 - 19:30
Le Tue, 22 Nov 2005 09:02:30 +0100, Eric L. a écrit :

et en utilisant la propriété

..affichageactif = faux

avant ton traitement
et

..affichageactif = vrai

apres ton traitement ?!

juste une idée comme ca...!


ah tient je ne connaissais pas cette propriété. Je connais l'astuce
consistant à rendre invisible la table avant de la remplir (qui augmente en
effet grandement sur mon pocket de test la vitesse de remplissage [du
simple au double quasiement !]). Je vais comparer avec ce ..affichageactif.
C'est toujours intéressant à prendre merci.


En revanche, ce qui m'étonnait c'était la "dégradation" de perf au fur et à
mesure. La première fois la table se remplit vite (même en étant affichée
et raffraichie au fur et à mesure), la deuxième fois c'était bcp plus, etc.
Mais de façon complètement aléatoire...

En fait, j'ai commencé à explorer les voies du threadexecute() qui permet
pas mal de chose pour améliorer ce problème de goulet d'étranglement de
l'affichage... Ce qui fait que je fait charger les fenêtres un peu par
anticipation sur des phases où l'utilisateur devrait être "inactif"...

Encore, merci pour ce début de piste.

à+

--
Deg
ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez
m'écrire en privé.