UN DOEVENTS PLUS RAPIDE

Messages postés
135
Date d'inscription
jeudi 30 janvier 2003
Statut
Membre
Dernière intervention
12 juillet 2006
- - Dernière réponse : Herge89
Messages postés
1
Date d'inscription
jeudi 14 avril 2005
Statut
Membre
Dernière intervention
13 juillet 2006
- 13 juil. 2006 à 16:05
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/20535-un-doevents-plus-rapide

Afficher la suite 
Herge89
Messages postés
1
Date d'inscription
jeudi 14 avril 2005
Statut
Membre
Dernière intervention
13 juillet 2006
-
Quand on cherche la performance on code pas en VB :)

Désolé de vous avoir laissé galérer plus de 2 ans pour rien avec ce langage lol.

Bravo quand même à MadLucas pour la clarté de tes explications.
jockos
Messages postés
321
Date d'inscription
dimanche 22 octobre 2000
Statut
Membre
Dernière intervention
14 mai 2005
2 -
La version en C++ pour ceux que ça interresse...
http://www.cppfrance.com/code.aspx?ID=9878
gandalfkhorne
Messages postés
70
Date d'inscription
dimanche 11 janvier 2004
Statut
Membre
Dernière intervention
1 octobre 2004
-
Je trouve ce code très intéressant car dans le cas du cryptage il évite une perte de temps phénoménal.

Merci encore ;-)
Afyn
Messages postés
613
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
-
-> Proger
Je pense pas que DoEvents dure 1ms ...
A mon avis, il rend la main immédiatement ...
Au moins dans certain cas.
Ds Mon WaitableTimer en forcant la Priorité sur Critical en tout cas ...
Si quelqu'un arrive a mesurer !

A+
Afyn
Proger
Messages postés
248
Date d'inscription
vendredi 10 novembre 2000
Statut
Membre
Dernière intervention
19 décembre 2008
-
Pour continuer le débat là ou s'arrête MadLucas :
Mais alors si DoEvents fait rigoureusement la même chose que le DoEv de Unreal, comment expliquer que DoEvents est *plus lent* que DoEv ?
Petite piste à 10 balles : DoEvents (aka rtcDoEvents dans msvbvm60.dll) , en outre de plaçer le message du processus en cours en fin de stack win, ne doit-il pas non plus gérer l'IDE de vb ? je suppose que l'api rtcDoEvents, en plus de faire la même chose que DoEv, doit également vérifier un ensemble de paramètres dans l'environnement VB (peut être même lançer un thread pour récupérer l'interruption Ctrl+Pause ...) d'où l'apparente "lenteur".
Par la pratique on remarque que DoEvents dure "au moins" 1 millisecondes, ce qui pose des problèmes de préçision dans les boucles.
Nota : lorsque on compile le programme de test, laquelle des 2 fonctions est la plus rapide ?

Sinon pour ce qui est de faire tourner son appli en "arrière-plan", rien de tel qu'un SetPriorityClass vers idle...
cs_Unreal
Messages postés
89
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
26 mars 2006
-
DoEvents est bien dans MSVBVM60.DLL:
Vous l'ouvrez avec Application WordPad MFC, vous recherchez dans le fichier "MSVBVM60.DLL", il va le trouver et juste à coté il y a les fonctions: vous y trouverez rtcDoEvents. C'est fort possible que ce soit la fonction demandée.
@++ Flo
LogRaam (aka Gabriel Mailhot)
Messages postés
60
Date d'inscription
lundi 26 mai 2003
Statut
Membre
Dernière intervention
25 avril 2005
-
Mmmhpf... Ok.

DoEvents ne donne pas un tour de plus au CPU, il n'accélère pas non plus une application et oui il peut ralentir considérablement une application.

Mais alors, pourquoi l'intérêt de DoEvents ?

Pour bien comprendre son rôle, il faut comprendre comment le coeur même de Windows fonctionne. En gros, Windows roule en permanence une "boucle infinie" qui gère des "messages" qui s'empilent dans une "pile". Ces messages peuvent être par exemple un click de souris, une demande de Refresh d'une fenêtre, un appel d'un timer, etc. Tous les messages sont empilés les uns à la suite des autres dans la "Stack" (pile) et sont gérés selon leur "ordre" et selon leur "niveau de priorité". C'est justement la fameuse boucle "TranslateMessage" et "DispatchMessage" qui traite tout ça.

Si par exemple vous exécutez une boucle Do..Loop dans votre code (calculs seulement, pas d'attente d'interaction de l'usager car le status "Idle" redonne en quelque sorte le contrôle à Windows), VB envois un message dans la Stack de Windows. lorsque la boucle de gestion de Windows reçoit le message, il l'exécute. Si par exemple VB donne une priorité 3 à votre code, votre code se placera à la fin de tous les messages de même priorité qui sont déjà dans la Stack. Lorsque Windows exécutera votre message, il attendra de le terminer avant de passer aux autres messages de même niveau (ou inférieur); seul les niveau 2 et 1 seront alors gérer en priorité par la boucle de gestion. L'usager remarque alors que l'application "gèle" ou que l'ensemble du système "lag".

Le vrai rôle de DoEvents est de dire à Windows de prendre le message de votre code et de le replacer à la fin de la file d'attente qui correspond à son niveau de priorité, de sorte que Windows gère les autres messages qui se sont accumulés dans la Stack pendant l'exécution de la boucle Do..Loop. Dans cette optique, DoEvents va ralentir la vitesse à laquelle votre boucle s'exécutera en lui enlevant temporairement le focus du CPU. D'une autre part, vous regagnez un peu de contrôle par rapport au reste du système d'exploitation en gérant tous les messages accumulés.

Un bon exemple de l'utilité de DoEvents est quand vous dessinez des PSet dans un objet Picture. Si vous exécutez les PSet dans une boucle, l'image final apparaîtra à la fin du traitement. Si par contre vous utilisez DoEvents dans votre boucle, il est alors possible de voir chacuns des PSet s'afficher dans l'objet Picture. Logique car à chaque fois que vous appelez PSet, un message WM_PAINT s'insère dans la Stack de Windows en attente d'être traité à son tour.

Bon, c'est assez difficile de vulgariser sur ce sujet par écrit.. J'espère que je vous ai pas trop perdu avec mon exposé.



MadLucas
cs_azerty25
Messages postés
1115
Date d'inscription
jeudi 19 décembre 2002
Statut
Membre
Dernière intervention
6 mai 2007
-
Pourquoi des routines seraient dans une dll externe déja ?! vous avez des preuves avt d'afirmer sa ?! Parce que j'ai jamais vu d'écrit pour l'instant l'affirmant ...
Bricomix
Messages postés
340
Date d'inscription
vendredi 11 octobre 2002
Statut
Membre
Dernière intervention
14 février 2005
-
Ben je sais pas trop si DoEvents est dans MSVBMV ou autre mais le fait est que la plupart des fonctions VB sont dans cette DLL on peut supposer la meme chose pour DoEvents. Ce qui expliquerait en partie que DoEv soit plus rapide que la version krosoft !! Si DoEvents était direct intégré au code, je pense que ce serait plus rapide que ça ;)
cs_Unreal
Messages postés
89
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
26 mars 2006
-
Un moyen de tester:

'1/Microsoft
'Dans une form
Private Sub Form_Load()
Dim Cont, Tim
Show
Cont 0: Tim Timer
Do
Cont = Cont + 1
If Timer - Tim >1 Then Caption Cont: Cont = 0: Tim = Timer
DoEvents
Loop
End Sub

'2/DoEv
'Dans une form
Private Sub Form_Load()
Dim Cont, Tim
Show
Cont 0: Tim Timer
Do
Cont = Cont + 1
If Timer - Tim >1 Then Caption Cont: Cont = 0: Tim = Timer
DoEv
Loop
End Sub


Chez moi, DoEv, cest plus rapide. peut-être dépend-il du pc? (Moi = P3 733Mhz)

@++ Flo
cs_Unreal
Messages postés
89
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
26 mars 2006
-
Mais c'est vrai que de déclarer msg_ à l'exterieur de la procédure augmenterai la vitesse:

'Api's

Public Declare Function PeekMessage Lib "user32" Alias "PeekMessageA" (lpMsg As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax As Long, ByVal wRemoveMsg As Long) As Long
Public Declare Function TranslateMessage Lib "user32" (lpMsg As MSG) As Long
Public Declare Function DispatchMessage Lib "user32" Alias "DispatchMessageA" (lpMsg As MSG) As Long

'Types
Public Type POINTAPI
x As Long
y As Long
End Type

Public Type MSG
hwnd As Long
message As Long
wParam As Long
lParam As Long
time As Long
pt As POINTAPI
End Type

'Constantes
Public Const PM_REMOVE = &H1
Public Const PM_NOYIELD = &H2
Public Const PM_NOREMOVE = &H0

Dim msg_ As MSG 'Déclaration de la variable
'Fonction
Sub DoEv()
Do While PeekMessage(msg_, 0, 0, 0, PM_REMOVE) 'Vide la pile
TranslateMessage msg_
DispatchMessage msg_
Loop
End Sub

' Remarque : Si vous Mettez PM_NOREMOVE Votre systeme reste bloqué pour je ne sais quelle raison. Apparament il ne doit pas vider la pile d'attente
cs_Unreal
Messages postés
89
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
26 mars 2006
-
Je suis plus sûr de mon code, j'ai testé, ça a marché, mais si vous avez d'autres idées pour l'améliorer, je suis preneur :-)
@++ Flo
cs_Jack
Messages postés
14008
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
61 -
Voilà comment je vois les choses :
"DoEvents" permet de rendre la main au système pour un tour d'horloge du CPU, c'est à dire le temps suffisant pour que le CPU traite toutes les interruptions gestion clavier, écran, souris et autres applications). Si les autres applications tournant sur la machine sont bien programmées et repasse la main au système quand c'est utile, un DoEvents ne dure pas longtemps.
Par contre, si votre application repasse la main au système avec un DoEvents et que d'autres zapplications font des boucles interminables, là, oui, ça risque de durer longtemps.
De toute façon, ce n'est qu'une question de priorité pour savoir quelle tache se terminera avant les autres en ayant pris le plus de temps machine.
Si vous voulez garder une fluidité sur votre machine, placez des DoEvents assez souvent.

En ce qui concerne la source de Unreal :
Peux-tu me confirmer qu'en fait, cette fonction attend que la pile des taches en cours soit vide ?
Si c'est le cas, cela permettrait à l'application qui l'utiliserait, de ne tourner que lorsque le CPU est libre, comme le font les programmes de calculs comme Seti@home, en arrière plan --> Interessant, non ?

Vala
Afyn
Messages postés
613
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
-
Je persiste ...
Même dans une boucle qui dure longtemps, qu'elle dure 7 ou 8 ou 9 secondes importe peu ... (donc on est pas pressé !)
C'est ma façon de voir la chose.

A+
Afyn
cs_DARKSIDIOUS
Messages postés
15838
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
79 -
Bricomix >>> L'utilisation de DoEvents nécessite la dll MSVBMV ? Je ne savais pas !

Afyn >>> L'utilisation de DoEvents ne signifie pas qu'on n'est pas pressé, vu que dans la plupart des cas, lorsqu'on l'utilise dans de grandes boucles (entend par là, des boucles qui dure longtemps), cela permet de gagner du temps et de ne pas bloquer le système !

DarK Sidious
Afyn
Messages postés
613
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
-
Si tu veux l'accellerer un peu plus tu déclares msg_ en dehors
de DoEv() ...
De toutes façon, quand on utilise DoEvents, c'st qu'on est pas pressé ?
A+

Afyn
Bricomix
Messages postés
340
Date d'inscription
vendredi 11 octobre 2002
Statut
Membre
Dernière intervention
14 février 2005
-
Tu es sûr que les fonctions sont directement dans l'EXE ? Dans ce cas, pourquoi faut-il des DLL (MSVBMV.DLL) ??
cs_DARKSIDIOUS
Messages postés
15838
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
79 -
Es-tu bien sûr que ce soit plus rapide ? Car l'appel des fonctions API doivent être, en théorie, plus lent que l'appel des fonctions VB directement compilées dans l'exe !

DarK Sidious
cs_Unreal
Messages postés
89
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
26 mars 2006
-
Voila, c'est fait
@++ Flo
cs_Unreal
Messages postés
89
Date d'inscription
vendredi 20 décembre 2002
Statut
Membre
Dernière intervention
26 mars 2006
-
J'ai oublié de le commenter attendez je vais le faire :-)
loskiller62
Messages postés
135
Date d'inscription
jeudi 30 janvier 2003
Statut
Membre
Dernière intervention
12 juillet 2006
1 -
Intéressant. A tester bien sûr... je garde ça sous la main en attendant :-)
Bien joué