MsgBox verlangsamt den Skriptablauf unter Win 10

  • (27.04.2020 / 22:30 Uhr):

    Erneut ein kurzes Update zum aktuellen Stand im englischen Forum (für die, die dort nicht mitlesen können/wollen) :

    Erfreulicherweise hat sich Jon (der Entwickler von AutoIt) dem Problem gewidmet und ist gerade auf der Suche nach einer Lösung.

    Ich habe mir die Freiheit genommen, und auf die "Forschungsarbeit" von chesstiger - siehe Beitrag oben - hingewiesen (ich hoffe, das ist Dir recht). Offenbar wird Dein Verdacht bzgl. PeekMessage(W) bestätigt ;).

    Hier das letzte Statement von Jon : script-becomes-way-slower-after-a-msgbox

    "I've narrowed this down to the Win32 PeekMessage function. This is called every script line to check for user quit / gui messages. The function runs fine until ANY GUI element is made visible. As soon as that happens PeekMessage takes 10 times longer to return. It's almost certainly a bug/design change in Windows 1809+.

    Edit: I just did a google translate on that German thread and PeekMessage mentioned there too."

    (frei übersetzt)

    "Ich habe dies auf die Win32 PeekMessage-Funktion eingegrenzt. Diese wird in jeder Skriptzeile aufgerufen, um nach User Quit/Gui-Meldungen zu suchen. Die Funktion läuft gut, bis IRGENDEIN GUI-Element sichtbar gemacht wird. Sobald das passiert, braucht PeekMessage 10 Mal länger, um zurückzukehren. Es handelt sich mit ziemlicher Sicherheit um eine(n) Fehler/Design-Änderung in Windows 1809+.

    Edit: Ich habe gerade eine Google-Übersetzung für den deutschsprachigen Thread gemacht und PeekMessage wird dort auch erwähnt."

    Gruß Musashi

    P.S. : Es gibt im engl. Forum einen User namens Chesstiger - bist Du das ? Falls ja, editiere ich meinen Beitrag dort, sodass die Meriten an die richtige Adresse gehen :).

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (28. April 2020 um 00:54) aus folgendem Grund: typo - Dank an Bitnugger

  • Die Funktion läuft gut, bis JEDES GUI-Element sichtbar gemacht wird.

    Hier hast du dich vertan... nicht JEDES, sondern EIN...

    Google übersetzt den Satz so: Die Funktion läuft einwandfrei, bis ein beliebiges GUI-Element sichtbar gemacht wird.

  • Hier hast du dich vertan... nicht JEDES, sondern EIN...

    Wo Du recht hast, hast Du recht :P.

    Zwar findet man bei den Übersetzungen von some und any verschiedene Varianten, aber hier ist "Die Funktion läuft gut, bis (irgend-)ein GUI-Element sichtbar gemacht wird." richtig.

    Ich habe das Statement einfach durch den Übersetzer gejagt, um anderen die Mühe zu ersparen.

    Wahrscheinlich war ich auch noch so überwältigt, dass Jon sich der Sache angenommen hat ^^.

    Mit AutoIt-Compilern und Multithreading können wir wohl nicht mehr rechnen, aber das ist mir egal.

    Wichtiger ist mir, dass ein 'unglückliches' Windows-Update nicht den sofortigen Tod nach sich zieht.

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Am Besten wäre Open Source :rock:

    Einfach den Code auf Github und ab gehts.

    Ein Lösungsansatz wäre sowas wie:
    EventsOff()
    Code der schnell laufen soll
    EventsOn()

    Es ist doch auch wahnsinn, dass man in JEDER ProgrammZEILE checkt ob der User auf X geklickt hat. Das sieht für mich nach 99% Overhead im Interpreter aus.

  • Am Besten wäre Open Source :rock:

    Einfach den Code auf Github und ab gehts.

    Hi Mars !

    Genau DAS wird wahrscheinlich nicht passieren :(.

    @Jos hat im englischen Forum (Bereich CHAT : Link ) auf einen Thread verwiesen, der Hintergründe aus der Anfangszeit von AutoIt beschreibt. Da CHAT nur für Mitglieder mit 20+ Beiträgen zugänglich ist, hier der entsprechende Link : licensing-opinions

    Ich möchte nur einen der Kernpunkte nennen (ohne Prüfung auf Richtigkeit und/oder der rechtlichen Aspekte) :

    Der Sourcecode von AutoIt wurde bereits mal unter GPL-Lizenz (2003..2005 ?) offengelegt. In dieser Zeit entstand auch der Fork (die Abspaltung) AutoHotkey . Dabei haben sich der/die "Entwickler" von AHK wohl "sehr freizügig" an der geleisteten Vorarbeit der AutoIt-Devs bedient - z.T. sind angeblich sogar die Danksagungen (Credits) aus den Funktionen entfernt worden usw."

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Wieso muss ICH Fehler ausbaden die zu einer Zeit passiert sind als ich 10 Jahre alt war und mit einer Trommel um den Weihnachtsbaum gerannt bin?

    Ich bin dafür, dass Leute die im DE Forum Poweruser sind (die werden ja durch die Community ernannt, sind also üblicherweise Leute die "in Ordnung" sind und teilweise auch als Informatiker/Programmierer arbeiten, also ein bisschen know how haben, ein paar Jahre dabei sind, usw.) am Code mitarbeiten dürfen. Wie es im EN Forum mit MVP's aussieht weiß ich nicht, da ich da zwar einen Acc habe aber nie aktiv bin.

    (Das ist jetzt Offtopic, aber im Prinzip musste ich das hier ergänzen weil es aktuell nur hier hinpasst)

    M

  • Wieso muss ICH Fehler ausbaden die zu einer Zeit passiert sind als ich 10 Jahre alt war und mit einer Trommel um den Weihnachtsbaum gerannt bin?

    Hey, für die Sachlage bin auch ich nicht verantwortlich.

    Nebenbei : Ich habe gehört, dass Du immer noch gerne mit der Trommel um den Baum rennst :P.

    Ich bin dafür, dass Leute die im DE Forum Poweruser sind (die werden ja durch die Community ernannt, sind also üblicherweise Leute die "in Ordnung" sind und teilweise auch als Informatiker/Programmierer arbeiten, also ein bisschen know how haben, ein paar Jahre dabei sind, usw.) am Code mitarbeiten dürfen. Wie es im EN Forum mit MVP's aussieht weiß ich nicht...

    Sehe ich zwar ähnlich, aber diese Entscheidung liegt nun mal ausschließlich bei Jon :!:

    Meines Wissens gibt es nur seeehr wenige Leute, die am aktuellen Core schrauben können/dürfen. Die englischen MVP's gehören anscheinend nicht dazu.

    Daher bin ich ja auch so froh, dass Jon zumindest wieder etwas Interesse zeigt.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Nebenbei : Ich habe gehört, dass Du immer noch gerne mit der Trommel um den Baum rennst :P .

    Pschhhhht. :D

    Mir ist jetzt erst aufgefallen, dass dieser Thread in "Forum -> Sonstiges -> Off-Topic" liegt. Und ich hatte schon Angst zu sehr vom Thema abzuweichen :part:

  • Gruß Musashi

    P.S. : Es gibt im engl. Forum einen User namens Chesstiger - bist Du das ? Falls ja, editiere ich meinen Beitrag dort, sodass die Meriten an die richtige Adresse gehen :) .

    Musashi Yes, das bin ich. Trete da aber nicht wirklich in Erscheinung. Da ist mir die deutsche Community lieber.

    Aber schön, dass Jon mit Zugriff auf den Sourcecode zum selben Ergebnis kommt wie ich mit externen Tools. 8)

    Ansonsten gebe ich euch recht. Es wäre wirklich cool, wenn wir am Core mitarbeiten könnten. Im Endeffekt ist das zwar Jons gutes Recht - aber ich glaube, wir würden alle davon profitieren.

  • MVPs arbeiten nicht am Core mit, haben aber die Möglichkeit im Repository an den UDFs und der Doku rumzuschrauben.
    Jon ist wahrscheinlich auch sehr, sehr vorsichtig mit Leuten, die am Core rumfummelnd dürfen. Da gab es schlechte Erfahrungen mit Codern, deren großes Ego Kompromisse oder andere Sichtweisen nicht zuliessen.

  • MVPs arbeiten nicht am Core mit, haben aber die Möglichkeit im Repository an den UDFs und der Doku rumzuschrauben.
    Jon ist wahrscheinlich auch sehr, sehr vorsichtig mit Leuten, die am Core rumfummelnd dürfen. Da gab es schlechte Erfahrungen mit Codern, deren großes Ego Kompromisse oder andere Sichtweisen nicht zuliessen.

    Wenigstens gäbe es dann einen Fortschritt und keinen Stillstand, auch wenn der Verlauf nicht unbedingt dem entspräche, was sich Jon vorstellt. Soweit ich mich noch erinnern kann, gab es coole Ideen, wie sich Autoit weiter entwickeln könnte...

    Apropos Jon, anscheinend schreibt er lieber coole Amiga Demos anstatt sich um die Entwicklung von AutoIt zu kümmern....

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Da gab es schlechte Erfahrungen mit Codern, deren großes Ego Kompromisse oder andere Sichtweisen nicht zuliessen.

    ...es kann nur einen geben....VALIK:rock:

    Der war übrigens der einzige Grund, dass ich mich damals überhaupt im "blauen" Forum angemeldet hatte...seine "liebreizende" Art fand ich einfach einfach nur herzerfrischend

  • ...es kann nur einen geben....VALIK :rock:

    YES :D

    Immer wenn ich über ältere Beiträge von Valik stolpere, dann muss ich zwangsläufig an Dich denken. Schade, dass er nicht mehr aktiv ist !

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • trancexx hatte auch klasse Ideen, wie die Zukunft von Autoit aussehen könnte, aber da gab es auch Differenzen, die zum Ausstieg von trancexx geführt hatten.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • trancexx hatte auch klasse Ideen, wie die Zukunft von Autoit aussehen könnte, aber da gab es auch Differenzen, die zum Ausstieg von trancexx geführt hatten.

    Ja, die Liste ist doch recht lang :(.

    Zumindest ist trancexx noch (halbwegs) aktiv, d.h. schaut gelegentlich in das Forum.

    Wir hatten erst vor kurzem eine Konversation in der sie andeutete, dass sie auch in Zukunft den Faden nicht völlig abreissen lassen möchte. Die Frage, warum sie nicht mal mehr als MVP gerankt wird (eigener Wunsch oder 'Degradierung') habe ich aus Höflichkeit allerdings nicht gestellt.

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Ich lese hier zwar hauptsächlich nur mit, aber ich freue mich, dass das Interesse an dem Thema hoch gehalten wird. Besonderen Dank an Musashi , dass du uns auf dem neuesten Stand hältst! :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • (Stand 01.05.2020 / 15:30 Uhr):

    Jon hat sich im engl. Forum mit folgender Bitte gemeldet :

    (übersetzt mit http://www.DeepL.com/Translator - minimal von mir überarbeitet)

    Anfrage von Jon

    Ich würde gerne einige Tests durchführen lassen, falls jemand helfen möchte.

    https://www.autoitscript.com/autoit3/files/…toit/win10slow/

    Das Problem ist, dass win32 PeekMessage verrückt langsam wird, nachdem irgendein Gui-Element nach Win10 1809 gezeigt wird. Je nachdem, wie ein Programm geschrieben wird, wirkt sich dies auf viele andere Programme aus... Sieht für mich wie ein echter Fehler aus, aber zweifellos wird es ihn noch jahrelang geben.

    Die richtige Lösung wäre ein von Grund auf neu zu schreibendes Anwendungsszenario, bei dem sich die Nachrichtenverwaltung und die Benutzeroberfläche auf einem Thread befinden und der Skriptcode auf einem anderen läuft. Ich habe mir eine Nachrüstung in AutoIt angesehen, aber es würde wahrscheinlich viele GUI-Skripte kaputt machen, so dass ich, obwohl ich im Hintergrund herumbastle, nicht glaube, dass es machbar ist. Die Funktionen CreateWindowEx/SetWindowLongPtr (unter anderem) und PeekMessage/Ereignisschleife müssen auf dem selben Thread laufen, so dass es kompliziert wird, da man bei vielen Benutzercodes, in denen GUIs erstellt werden, einen Thread dazu bringen muss, Fenster in einem anderen Thread zu erstellen. Eine Menge Code vom Typ DllCall (winapi-Bibliothek) würde wahrscheinlich explodieren.

    Als schmutzigen Hack versuche ich, die Aufrufe an PeekMessage zu drosseln. In AutoIt prüfen wir bei jedem "Zyklus", der zwischen jeder Skriptzeile und während Funktionen vom Typ Sleep/WinWait liegt, auf neue Nachrichten. Wenn Sie dies auf alle ~64 Aufrufe drosseln, wird die Verlangsamung klein.

    Ich habe versucht, GetQueueStatus anstelle dieses fiesen Drossel-Hacks zu verwenden, um zu prüfen, ob vor dem Aufruf von PeekMessage eine Nachricht wartet, aber GetQueueStatus war noch langsamer (was bringt das??). GetInputState (prüft, ob eingabebedingte Nachrichten warten) scheint schnell zu sein, also habe ich das benutzt.

    In den obigen Test Exes habe ich es extrem stark gedrosselt, um bei der Fehlersuche nach AutoIt Funktionen zu helfen, die von der Drosselung betroffen sind, so dass der aktuelle Code PeekMessage nur in den folgenden Fällen ausführt:

    GetInputState zeigt Benutzereingaben an (Benutzer bewegt die Maus und interagiert mit einer GUI)

    Die Drosselzählung beträgt 2048 (um die Fehlersuche zu erleichtern, wird dieser Wert reduziert, wenn diese Abhilfe möglich ist)

    GuiSetState wurde soeben ausgeführt

    GuiGetMsg wurde gerade ausgeführt

    ( Bitnugger : bitte nachsichtig sein bzgl. sprachlicher Merkwürdigkeiten ;))


    Leider habe ich momentan keinen Win 10 Rechner im Zugriff, aber ggf. können chesstiger und andere das im Auge behalten ( UEZ hat bereits geantwortet).

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Na das ist ja schon mal ein gewaltiger Unterschied!

    2 Mal editiert, zuletzt von Bitnugger (1. Mai 2020 um 20:51) aus folgendem Grund: Edit: Test mit GUIOnEventMode erweitert

    • Offizieller Beitrag

    Bei mir sieht das so aus: