Discussion :

[BeanzMaster]

J'ai utilisé le convertisseur automatique, et étant donné que j'utilise que des composants (standard) il y a eu aucun
problème de conversion.

À mon avis Delphi détecte mon CPU 64 bits et le compile en conséquence. Je vais m'arranger pour compiler en 64 bits
pour voir la différence.

En ce qui concerne mon code source, j'imagine que si je le met ici, toute la communauté vas pouvoir le voir. Pour
l'instant j'aime mieux pas, mais je pourrais zipper le exe avec ces fichiers.

Fernand, Salut!

Salut Fernand, l'exe ne nous sera pas utiles. Sans les sources et sans voir les options de compilations dur de t'aider.
L'utilisation du convertisseur automatique n'est pas optimal. De plus si les source sont en {$mode Delphi} L'optimisation au niveau du compilateur n'est pas optimum.

Si tu le souhaites envoie moi un mp avec un lien de partage via Dropbox ou autre service comme WeTransfer par exemple. Je pourrais jeter un oeil et t'aiguiller sur la compilation et autre optimisations.

A+
Jérôme

[fernet]

Bonjour BeanzMaster!
Pour ce qui est de mon OS c'est bien Win10 32 bits. Pour ce qui est des registres 64 bits, bien je n'ai plus de Delphi
sur ma machine sauf Delphi7 qui n'est pas installé, mais je suis presque sûre de n'avoir jamais vus ces registre 64 bits
en mode debug sous Delphi DX10.3.2.

Alors si les deux exécutables sont 32 bits, l'optimisation par des moyens comme utilisé (in) au lieu de (<,>,<>) ne
règlera pas le problème car çà optimise pour les deux camps.

Pour ce qui est du transfère des fichiers sources, j'étudie la questions pour voir si je peut le faire avec (OneDrive)
ou si non, il faudra que j'installe un programme.

En attendant je te met ici les options du compilateur sans les chemins (-uf) pour voir si çà peut t'aiguiller quelque peut.

C:\lazarus\fpc\3.2.2\bin\i386-win32\fpc.exe
-Ratt -MDelphi -Scghi -CX -O3 -XX -WG -l -vewnhibq -vm3036
-Filib\i386-win32
-FElib\i386-win32
-olib\i386-win32\Projechec.exe
-dLCL -dLCLwin32 -dBorland -dVer150 -dDelphi7 -dCompiler6_Up -dPUREPASCAL

Fernand, salut!

[BeanzMaster]

Bonjour Fernand

Pour ce qui est du transfère des fichiers sources, j'étudie la questions pour voir si je peut le faire avec (OneDrive)
ou si non, il faudra que j'installe un programme.

Oui cela devrait être possible avec OneDrive si c'est comme le GoogleDrive tu peux partager une url sinon comme je te le disais via un service en ligne comme https://wetransfer.com c'est gratuit faut juste t'inscrire ou sinon sans inscription https://www.sendgb.com/fr/ ou https://ufile.io par exemple

En attendant je te met ici les options du compilateur sans les chemins (-uf) pour voir si çà peut t'aiguiller quelque peut.

Ca n'aide pas vraiment car tu as beaucoup d'autre options d'optimisations disponibles




A+
Jérôme

[fernet]

Bonjour !

Selon mes derniers tests de performance, l'exécution du programme en Lazarus est plus rapide que celle de Delphi. Cependant il semblerait que FPC aie plus de difficulté avec l'instruction (Application.Processmessage(A.P)).

À mon avis cette instruction a pour première tâche de lire le registre des drapeaux et si il est égal à zéro ça veut dire que l'utilisateur ne demande rien et on retourne tout de suite à l'exécution.

Alors je ne comprends pas, si je place (A.P) à un endroit de mon programme où il est plus souvent sollicité, Lazarus devient plus lent que Delphi.

Fernand, merci !

[Guesset]

Bonjour,

Application.ProcessMessage ne traite pas que les messages utilisateur mais également les messages du système à destination de l'application et ceux provenant de l'application elle-même (éventuellement à sa propre destination).

Je ne sais pas si c'est le cas ici, mais si un traitement demande une haute priorité d'exécution cela bloque souvent le traitement des messages dont les mises à jour de l'affichage. C'est gênant pour l'utilisateur, aussi faut-il réintroduire des Application.ProcessMessage en prenant soin de ne pas détruire le gain de vitesse offert par la montée en priorité.

Il est vraisemblable que le comportement de Application.ProcessMessage n'est pas exactement le même entre Delphi et Lazarus (je pense à un time out ou un quottât différent de messages traités avant de rendre la main).

Si c'est le cas, il appartient au développeur de choisir où et quand introduire Application.ProcessMessage. Le critère temps est le plus facile : en lisant un temps écoulé pour décider si l'activations de Application.ProcessMessage est acceptable. Le 1/10 s correspond à une réactivité assez bien tolérée.

Salutations

[fernet]

Bonjour !

Guesset
Il est vraisemblable que le comportement de Application.ProcessMessage n'est pas exactement le même entre Delphi et Lazarus (je pense à un time out ou un quottât différent de messages traités avant de rendre la main).

Bon d'accord, cependant pour Application.ProcessMessage(A.P) j'ai fait les testes d'exécutions suivant en
plaçant (A.P) a différente profondeur du jeu d'échec pour Lazarus et Delphi:

- (A.P) au plus profond: Lazarus(61 sec) Delphi(40 sec)
- (A.P) au mie profond: Lazarus (29 sec) Delphi(32 sec)
- (A.P) enlever du jeu: Lazarus (23 sec) Delphi(29 sec)

Bien sur le teste sans (A.P) est fait juste par curiosité, mais on voit très bien que Lazarus prend le dessus
sur Delphi si (A.P) est mieux placé.

Je trouve quant même que ça fait beaucoup de différence et qu'il y a peut être moyen d'optimiser cette
instruction, c'est à vous de voir.

Fernand, merci!

[BeanzMaster]

Bonjour !


Bon d'accord, cependant pour Application.ProcessMessage(A.P) j'ai fait les tests d'exécution suivants en plaçant (A.P) à différentes profondeurs du jeu d'échecs pour Lazarus et Delphi :

- (A.P) au plus profond: Lazarus(61 sec) Delphi(40 sec)
- (A.P) au mie profond: Lazarus (29 sec) Delphi(32 sec)
- (A.P) enlever du jeu: Lazarus (23 sec) Delphi(29 sec)

Bien sur le teste sans (A.P) est fait juste par curiosité, mais on voit très bien que Lazarus prend le dessus
sur Delphi si (A.P) est mieux placé.


Fernand, merci!

Bonjour, les questions à te poser sont :

Application.processMessage est-il vraiment nécessaire ?

Est-ce que l'utilisateur peut arrêter le traitement (en appuyant sur un bouton, par exemple) ?
Si oui, tu peux diminuer l'impact de A.P dans tes boucles en faisant un truc genre : if (i mod 10) then Application.processMessage(); pour i allant de 0 à 99. dans ce cas A.P sera appelé que 9x au lieu de 99x.

Si non, l'ultime solution serait d'exécuter ta fonction dans un thread, ce qui laisserait la form principale libre d'utilisation pour l'utilisateur. Et dans ce cas plus besoin de A.P.

[Guesset]

Bonjour,

Ce n'est pas AP qui consomme directement beaucoup de temps mais le traitement des messages en attente, notamment ceux qui concernent l'affichage. Par exemple, une simple barre de progression consomme beaucoup de ressources et si elle est mise à jour 100 fois par seconde, d'une part cela ne sert à rien, mais en plus pénalise le traitement suivi.

La solution du compteur proposée par Jérôme est simple et efficace mais suppose d'avoir une bonne idée du facteur de réduction souhaitable. J'utilise plutôt le temps qui est moins sensible à l'endroit où mettre l'appel. Cependant GetTickCount64 n'est pas garant d'un temps exact car il dépend de la machine (on peut cependant précalculer automatiquement un deltaTick correspondant à, par exemple, 1/10 s).

Code PASCAL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
         TickNew  := GetTickCount64;
         if TickNew - TickOld > 100 then begin     // Mode rapide : laisser l'application réactive
            TickOld := TickNew;
            Application.ProcessMessages;
         end;

La solution des threads de Jérôme est certainement la meilleures mais elle demande sans doute des modifications conséquentes du code.

Salutations

[fernet]

Bonjour!
Puisqu'il suffit de bien placer et de bien se servir d'Aplication.ProcesseMessage, j'en fais mon affaire.
Je remercie tous ceux qui ont participé a cette discussion que je vais clore la prochaine fois si personne ne s'y oppose.

Fernand, merci.

[BeanzMaster]

Bonjour,

Ce n'est pas AP qui consomme directement beaucoup de temps mais le traitement des messages en attente, notamment ceux qui concernent l'affichage. Par exemple, une simple barre de progression consomme beaucoup de ressources et si elle est mise à jour 100 fois par seconde, d'une part cela ne sert à rien, mais en plus pénalise le traitement suivi.

La solution du compteur proposée par Jérôme est simple et efficace mais suppose d'avoir une bonne idée du facteur de réduction souhaitable. J'utilise plutôt le temps qui est moins sensible à l'endroit où mettre l'appel. Cependant GetTickCount64 n'est pas garant d'un temps exact car il dépend de la machine (on peut cependant précalculer automatiquement un deltaTick correspondant à, par exemple, 1/10 s).

Code PASCAL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
         TickNew  := GetTickCount64;
         if TickNew - TickOld > 100 then begin     // Mode rapide : laisser l'application réactive
            TickOld := TickNew;
            Application.ProcessMessages;
         end;

La solution des threads de Jérôme est certainement la meilleures mais elle demande sans doute des modifications conséquentes du code.

Salutations

Hello, tu as raison, j'ai déja utilisé ta solution avec GetTickCount64 dans des boucles gérées avec while ou repeat car par forcément de compteur