MsgBox verlangsamt den Skriptablauf unter Win 10

  • Da nicht alle unsere Mitglieder im englischen Forum unterwegs sind (bzw. den Thread ggf. übersehen könnten), möchte ich auf das dort angesprochene Phänomen hinweisen :

    (Betrifft Windows 10)

    Ein User hat festgestellt, dass nach einem Aufruf von MsgBox (aber auch anderen "GUI Elementen" wie z.B. _ArrayDisplay usw.) die weitere Skriptausführung um bis zu einem Faktor von 6 verlangsamt wird.

    Originalthread : https://www.autoitscript.com/forum/topic/20…a-msgbox-moved/

    Da MsgBox laut Jos nur ein Standardaufruf der Windowsfunktion MessageBox ist, war die anfängliche Vermutung, es könnte sich um ein Windowsproblem handeln.

    Dies wurde mittlerweile wohl widerlegt, da das Problem in anderen Sprachen nicht auftaucht.

    Hier ein kleines Testskript (bei mir unter z.B. Win 7 sind die Zeiten quasi identisch) :

    Ihr könnt ja mal checken, wie es bei euch unter Win 10 aussieht.

    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."

    2 Mal editiert, zuletzt von Musashi (5. April 2020 um 00:32) aus folgendem Grund: lt. zu laut geändert, auf Wunsch von @autoiter :)

  • /OT

    Musashi Du kürzt laut mit lt. ab und reduzierst die Lesbarkeit, um dir ein Zeichen zu sparen? Serious? :D

    Btw. mein Ergebnis:

    > ------------------------------------------

    > >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

    ! Elapsed time = : 1102.230 ms

    > >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

    ! Elapsed time = : 14323.803 ms

    > ------------------------------------------

    Grüße autoiter

  • Da MsgBox lt. Jos nur ein Standardaufruf der Windowsfunktion MessageBox ist,

    Wer schreibt denn diesen Scheiß?

    Da geh ich wieder ab wie Schmitt´s Katze....

    Definitiv ist nicht auch nur annähernd ein "Standardaufruf" abgebildet!

    https://docs.microsoft.com/en-us/windows/…user-messagebox

    DAS ist der Standardaufruf!

    Bei der AutoIt-"Msgbox ist der 4. Parameter, also "timeout" hinzugefügt.....

    Was allerdings absolut nichts am Ergebnis ändert!

    Der DllCall der userdll32-MessageBox-Funktion führt bei mir zu identischem Zeitverhalten wie der Aufruf der AutoIt-Msgbox-Funktion...

    wzbw....

    > ------------------------------------------

    > >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

    ! Elapsed time = : 1506.213 ms

    > >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

    ! Elapsed time = : 8359.865 ms

    > ------------------------------------------


    //EDIT

    autoiter

    seltsam, deine Schleife läuft vor der Msgbox viel schneller als bei mir, aber danach wesentlich langsamer!

  • Hmm.
    Ich habe es mal auf einem neuen Notebook ausprobiert.

    > >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

    ! Elapsed time = : 657.558 ms

    > >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

    ! Elapsed time = : 2892.979 ms

    > ------------------------------------------

    Beide Ergebnisse (neu-alt) sind mit den üblichen Schwankungen reproduzierbar. Mit MsgBox Funktion und Dll Call.

    Beides Win 10 Pro 1903 buid 18362.720
    alt: Core i7 6500U
    neu: Cire i7 10510U

    Grüße autoiter

  • Es hat auch nichts mit der MsgBox zu tun. Ich habe mal ausprobiert, was Nine im EN Chat sagt. Das Problem tritt auch auf, nachdem man eine GUI anzeigt oder angezeigt hat...
    Eieiei.

    Grüße autoiter

  • Sehr interessante Sache...

    Bei mir sieht's ähnlich aus, allerdings ist die zweite Zeit im Verhältnis nochmal ein bisschen größer:

    > ------------------------------------------

    > >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

    ! Elapsed time = : 672.835 ms

    > >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

    ! Elapsed time = : 8955.305 ms

    > ------------------------------------------

    Wie autoiter schon meinte, tritt das Problem auch auf, wenn man anstatt der MsgBox z.B. Folgendes ausführt:

    AutoIt
    GUICreate("Test")
    GUISetState()
    GUIDelete() ; optional

    Getestet auf: Win 10 Pro 1909 (Build 18363.720)

    Viele Grüße

    Xenon

  • Wer schreibt denn diesen Scheiß? Da geh ich wieder ab wie Schmitt´s Katze....

    Na ja, das geht wohl z.T. auf meine Kappe. Ich habe die Aussage von @Jos :

    Zitat von Jos

    A call to MSGBOX is really a standard DLL call to MessageBoxW. ....

    möglicherweise zu vereinfacht dargestellt/übersetzt ;).

    Es hat auch nichts mit der MsgBox zu tun. Ich habe mal ausprobiert, was Nine im EN Chat sagt. Das Problem tritt auch auf, nachdem man eine GUI anzeigt oder angezeigt hat...

    Da MsgBox dieses Verhalten zumindest beeinflusst (siehe Testskript), hat es schon etwas damit zu tun, ohne jetzt auf die tieferen Hintergründe einzugehen bzw. eingehen zu können :P.

    Mir ging es in erster Linie erst einmal darum, auf dieses Phänomen hinzuweisen. Dass in einem zeitkritischen Skript ein simpler MsgBox-Aufruf solche Auswirkungen haben kann, mag manche sicher interessieren.

    Mal sehen, wie das ausgeht.

    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."

  • Stimmt natürlich.

    Ich hätte nicht schreiben sollen "nichts mit der MsgBox zu tun", sondern "nicht allein mit MsgBox zu tun". Natürlich ist der negative Effekt von InoutBox und MsgBox ja vorhanden.

    Grüße autoiter

  • Na ja, das geht wohl z.T. auf meine Kappe. Ich habe die Aussage von Jos :

    Ging ja nicht gegen dich :o)

    Die Adresse ist ganz klar Jos! Es werden seit Jahren eigentlich "native" Funktionen so hingebogen, dass diejenigen Funktionen, welche gerne von den "Power-Usern" (das hat jetzt weniger mit dem Titel in unserem Forum zu tun^^ ) benutzt werden, gegenüber den "einfachen" Funktionen (wie sie das "gemeine Volk" benutzen) besser abschneiden!

    Die künstliche Verlangsamung fast sämtlicher String-Funktionen war schon vor etlichen Jahren nachweisbar. Die kamen (damals) den (etwas komplexeren aka "langsamen") REGEXen Geschwindigkeitsmäßig wohl zu nahe. Da kamen im Forum immer wieder Dämpfer in Richtung der Regex-Verwender, dass das Problem des "einfachen" Users auch mit "einfachen", in diesem Fall String-Funktionen, zu lösen ist. Aber irgendwie muss man ja die sog. "Elite-Programmierer" bei der Stange halten....

    Um jetzt beim Thema zu bleiben, die Baustelle(n) in AutoIt sind längstens bekannt.

    Wobei auch bestimmt Windows einen dicken Anteil am "seltsamen" Verhalten einiger Scripte trägt.

    In diesem Jahr hatte ich schon etliche Infos von Usern bekommen, welche Probleme mit von mir erstellten Scripten hatten, die seit Jahren unverändert einwandfrei liefen und plötzlich (überwiegend Laufzeit-) Probleme machten.

    Ich habe das immer unseren (am Anschlag laufenden) Servern in die Schuhe geschoben. Wohl auch, weil VBA-Scripte in Excel ähnliche Probleme zeigten....:Glaskugel:

    Hehe, da hat wohl einer der zehntausend Windows-Entwickler wohl im Compiler ein falsches Häkchen gesetzt....und das neue(ste) Update reißt bis dahin völlig einwandfrei laufende Systeme in den Abgrund...schaumamal, ob daraus noch irgendwann etwas Gutes wird:theke:

  • Anscheinend tritt das Problem erst dann auf, wenn durch eine aufgerufene Funktion eine GUI erstellt wird... wobei es egal ist, ob diese danach noch existiert oder wieder gelöscht wurde.

    > ------------------------------------------

    > >>>>> Check 1 vor ... <<<<<

    ! Elapsed time 1 : 1069.034 ms

    ! Elapsed time 2 : 1070.383 ms

    ! Elapsed time 3 : 1057.873 ms

    > >>>>> Check 2 nach _ArrayDisplay <<<<<

    ! Elapsed time 1 : 7703.088 ms

    ! Elapsed time 2 : 7672.584 ms

    ! Elapsed time 3 : 7650.816 ms

    > >>>>> Check 3 nach GUIOnEventMode=1 <<<<<

    ! Elapsed time 1 : 9330.554 ms

    ! Elapsed time 2 : 9310.725 ms

    ! Elapsed time 3 : 9472.904 ms

    > ------------------------------------------

    • Offizieller Beitrag

    [OT - zumindest etwas]

    Unser Datenschutzverantwortlicher hatte mich letztens darauf hingewiesen, dass zwingend auf Windows 10 umgestellt werden müsse um der DSGVO gerecht werden zu können. Ich sagte ihm, dass er den Tag in unsrem Unternehmen eher nicht erleben wird. Er wirkte etwas verdutzt. Daraufhin habe ich ihm nochmals erklärt, dass es einen einfachen Weg gibt personenbezogene Daten von Windows-Schwachstellen fernzuhalten: Intranet! Keiner unserer Warenwirtschafts-PC hat irgendeine Möglichkeit ins INet zu verbinden, sind alle in einem eigenen Netz. Eigene Kabel und Switches - ebenso haben die extra Internet-PC ein komplett eigenes Hardware-Netz.

    Und wenn ich dann so sehe, was mit Win10 in steter Regelmäßigkeit für Probleme auftreten, müsste ich schon mit dem Klammerbeutel gepudert sein um solchen Dreck in die Firma zu integrieren.

    [/OT]

  • Ist ja unglaublich um wieviel das langsamer wird.....selbst eine simple msgbox statt dem Arraydisplay verlangsamt die Funktion um ~80%

    > ------------------------------------------
    > >>>>> Check 1 vor ... <<<<<
    ! Elapsed time 1 : 494.590 ms
    ! Elapsed time 2 : 495.710 ms
    ! Elapsed time 3 : 496.470 ms
    > >>>>> Check 2 nach _ArrayDisplay <<<<<
    ! Elapsed time 1 : 2697.546 ms
    ! Elapsed time 2 : 2702.127 ms
    ! Elapsed time 3 : 2702.208 ms
    > >>>>> Check 3 nach GUIOnEventMode=1 <<<<<
    ! Elapsed time 1 : 3546.251 ms
    ! Elapsed time 2 : 3548.194 ms
    ! Elapsed time 3 : 3550.487 ms
    > ------------------------------------------

    lg

    Racer

  • Solche "Benchmark"-zahlen sind ja schön und gut, aber kann das bitte jemand mal in einem realistischeren Szenario testen?

    Wo liegt denn genau das Problem? Werden Befehle generell langsamer ausgeführt? Brauchen Zeilen länger zum interpretieren?

    In dem Test wird nur eine Variable drei * fünf Millionen Mal inkrementiert, das ist gerade nicht aussagekräftig, da Skripte nicht nur Variablen inkrementieren.

    Fallen die Zeiten langsamer aus wenn bspw. fünf Befehle in einer Zeile ausgeführt werden oder ähnliches?

  • Habe mal was gebastelt. (ein Quick n Dirty Test einiger primitiver Funktionen wie Plus, Mal, Geteilt, usw)

    Gemessen wird die Zeit in µs pro Aufruf der Zeile. (Das ganze randomisiert damit keine Muster dazwischenfunken incl Abzug der Zeit für die "Leerfunktion"). Jede dieser Zeiten wird gewichtet und auf 1 normiert (auf MEINEM Computer, bei euch wird der Wert für "µs Gewichtet" vermutlich nicht immer ca. 1.0 sein. Das ist notwendig, damit die Ergebnisse am Ende vergleichbar sind. Stellt dazu in Zeile 4 einen Gewichtungsfaktor ein, sodass ihr beim ersten Bench() Aufruf ca. 1000 Punkte holt). Am Ende wird die Inverse des Mittelwerts mal 1000 als "Score" gewertet (zum schöneren Vergleich). Dieser ist Proportional zur Ausführgeschwindigkeit. (1000 = MEIN Computer, 500 = ein PC auf dem das Skript halb so schnell läuft).

    Einfach mal ausführen. Nach dem ersten Bench() wird ein ArrayDisplay geschaltet, dadurch ist das 2te Bench() (mit identischem Ablauf) wesentlich verlangsamt. Wie viel genau sich jede Funktion verlangsamt kann man im Array in Col 3 "µs Gewichtet" ablesen, wenn man zuvor einen Gewichtungsfaktor eingestellt hat sodass man im ersten Bench() aufruf ca. 1000 Punkte bekommt.

    Aber irgendetwas stimmt hier trotzdem nicht. Ich habe früher schon seeeehr oft versucht den "schnellst möglichen AutoIt Code" für irgendein Problem zu bekommen. Ein Geschwindigkeitsunterschied um den Faktor 7-8 wäre mir da sicherlich mal aufgefallen, zumal ich zum Debuggen oft ArrayDisplay nutze. Das kann doch nicht sein, dass das bis heute niemand gemerkt hat?! Meine Vermutung ist, dass es an Windows liegt. Irgendein Sicherheitslückenschließungsupdate das aus unerfindlichen Gründen exakt die Schnittstelle von AutoIt zu Windows trifft, sodass AutoIt davon maximal betroffen ist während andere "nur" 10% an Geschwindigkeit einbüßen. Die alternative wäre, dass es an AutoIt liegt, aber an der Exe (und vorallem an der BETA) hat sich seit Jahrzehnten nichts geändert und ich halte es für extrem unwahrwahrscheinlich, dass das ich das bis heute nicht mitgekriegt hätte wenn es schon immer so gewesen wäre.

  • Puh, das ist echt interessant. Ich teste Mars' Skript mal mit dem Kram, an den ich gerade über Remote Desktop drankomme...

    01. Notebook (Windows 10)

    Gewichtungsfaktor 0.85

    Code
    = = = Test Results = = =
    991.69 (100.00%)
    131.94 (13.30%)
    = = = System Info = = =
    CPU Name:        Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    CPU Physical Cores:    4
    CPU Logical Cores:    8
    OS Version:        WIN_10
    OS Build:        18362
    OS Arch:        X64

    02. Server 1 (Hyper-V, Windows Server 2019)

    Gewichtungsfaktor 0.28

    Code
    = = = Test Results = = =
    1006.03 (100.00%)
    387.00 (38.47%)
    = = = System Info = = =
    CPU Name:        AMD EPYC 7252 8-Core Processor
    CPU Physical Cores:    1
    CPU Logical Cores:    2
    OS Version:        WIN_2016
    OS Build:        17763
    OS Arch:        X64

    03. Server 1 (physikalisch, Windows Server 2019)

    Gewichtungsfaktor 0.75

    Code
    = = = Test Results = = =
    1055.76 (100.00%)
    268.10 (25.39%)
    = = = System Info = = =
    CPU Name:        AMD EPYC 7252 8-Core Processor
    CPU Physical Cores:    8
    CPU Logical Cores:    16
    OS Version:        WIN_2016
    OS Build:        17763
    OS Arch:        X64

    04. Server 2 (physikalisch, Windows Server 2012)

    Gewichtungsfaktor 0.23

    Code
    = = = Test Results = = =
    996.25 (100.00%)
    1014.38 (101.82%)
    = = = System Info = = =
    CPU Name:        Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
    CPU Physical Cores:    4
    CPU Logical Cores:    4
    OS Version:        WIN_2012
    OS Build:        9200
    OS Arch:        X64

    05. Server 2 (Hyper-V, Windows Server 2016)

    Code
    = = = Test Results = = =
    1052.24 (100.00%)
    1039.83 (98.82%)
    = = = System Info = = =
    CPU Name:        Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
    CPU Physical Cores:    2
    CPU Logical Cores:    2
    OS Version:        WIN_2016
    OS Build:        14393
    OS Arch:        X64

    Ich mache im Laufe des Sonntags mal einen Abstecher in die Firma und teste mal auf verschiedenen Clients... Windows Server 2019 ist aber auf jeden Fall auch betroffen. Auffällig ist, dass mein Server mit AMD Epyc CPU extreme Schwankungen aufweist. Das zweite Testergebnis fällt immer irgendwo zwischen 25 und 50 Prozent, was - verglichen mit meinem Notebook - eine echt große Schwankung ist. Dennoch scheint die AMD-CPU nicht ganz so stark davon betroffen zu sein (Faktor 2-4 verglichen mit Faktor 8 bei Intel). Edit: Bei den beiden Maschinen mit Windows Server 2019 möchte ich kurz auf die Build-Nummer hinweisen. Das ist die LTS-Variante von Server 2019, welche auf Windows 10 1809 basiert. Wenn es ein grundsätzliches Problem in Windows 10 ist, kann das also nicht erst mit 1904 oder 1909 aufgetreten sein.

    Das ist echt spannend.

    • Offizieller Beitrag

    Hmm...in der Tat sehr kritisch.

    Vor allem, weil wohl nicht direkt AutoIt Schuld daran ist. Wenn man nämlich in dem Script von Mars das _ArrayDisplay auskommentiert und stattdessen nur das About-Fenster von Windows öffnet (per DLL-Call), dann passiert dieser Performanceeinbruch trotzdem.

  • Solche "Benchmark"-zahlen sind ja schön und gut, aber kann das bitte jemand mal in einem realistischeren Szenario testen?

    Wo liegt denn genau das Problem? Werden Befehle generell langsamer ausgeführt? Brauchen Zeilen länger zum interpretieren?

    Ich quote mich dazu mal selbst...

    In diesem Jahr hatte ich schon etliche Infos von Usern bekommen, welche Probleme mit von mir erstellten Scripten hatten, die seit Jahren unverändert einwandfrei liefen und plötzlich (überwiegend Laufzeit-) Probleme machten.

    WENN das ein Windows-Problem sein sollte, dann eines, dass einer Handvoll User in einem Scriptforum aufgefallen ist. Sehr unwahrscheinlich imho...

    Da gibt es hunderttausende, wenn nicht Millionen Entwickler/User weltweit, die das letzte Quentchen Leistung aus ihrer Software rausholen (müssen) und keinem fällt etwas auf? Sehr unwahrscheinlich imho...

    Was allerdings sein könnte, wären eine "Änderungen" am Windows-Code, welche nur speziel(lst)e Anwendungen, wie bspw. einen "bestimmten" Script-Interpreter, beeinflussen.

    AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages.

    //EDIT

    das _ArrayDisplay auskommentiert und stattdessen nur das About-Fenster von Windows öffnet (per DLL-Call), dann passiert dieser Performanceeinbruch trotzdem.

    Das war in dem von mir geposteten Script zur AutoIt-Msgbox / user32dll-Messagebox ja identisch.

    Ich denke schon, dass der "Fehler" in irgendeiner Art und Weise im AutoIt-Compilat liegt.

    Zeit für ein Debugging des ausgeführten Codes zur Laufzeit....jemand fit in Assembler und Debugging?!:whistling:

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (5. April 2020 um 10:40)

  • Frage an Alle !

    Ich habe diesem Thread den Titel MsgBox verlangsamt den Skriptablauf unter Win 10 gegeben, da die MsgBox der ursprüngliche Auslöser war (andere GUI-Elemente habe ich im Startpost nur erwähnt).

    Mittlerweile haben wir ja festgestellt, dass unterschiedliche Faktoren eine Rolle spielen können.

    Daher würde ich den Titel gerne (aussagekräftiger) umbennen, und bräuchte mal Vorschläge.

    Bitte in die Shoutbox posten. damit dieser Thread nicht zugemüllt wird ;).

    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."

  • Was allerdings sein könnte, wären eine "Änderungen" am Windows-Code, welche nur speziel(lst)e Anwendungen, wie bspw. einen "bestimmten" Script-Interpreter, beeinflussen.

    Das ist dann wohl die freundliche Umschreibung dafür, dass Microsoft explizit auf AutoIt-Code reagiert und diesen verlangsamt (bzw. durch eine erweiterte Prüfung schickt etc.). Denen wäre es wahrscheinlich eh lieber, wenn alle Powershell verwenden würden.

    Nebenbei : Nutzt jemand parallel zufällig auch AutoHotkey und hat das dort mal ausprobiert ?

    (mein Home-Office ist Win10 freie Zone)

    Zeit für ein Debugging des ausgeführten Codes zur Laufzeit....jemand fit in Assembler und Debugging?! :whistling:

    Spaßvogel :P. Ausgerechnet mein Hauptkandidat dem ich das zutrauen würde stellt diese Frage.

    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."