Script becomes way slower after a msgbox - (Moved)

[MrCreatoR]

#RequireAdmin and running under x64 reduces this effect.

Win 10 (17763) x64.

Edited April 5, 2020 by MrCreatoR

[water]

I hate this Microsoft numbering scheme 🤬

[argumentum]

14 minutes ago, MrCreatoR said:

#RequireAdmin and running under x64 reduces this effect.

your version is "Version 1809 (October 2018 Update)" and me, testing 1903, shows that you say but the difference is on #RequireAdmin only.

..is on x86 ( slower ) , vs x64 ( faster )

For $n = 0 To 1
    AutoItSetOption('GUIOnEventMode', $n)
    $x = 0
    $start = TimerInit()
    For $i = 1 To 500000
        $x += 1
    Next
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : TimerDiff($start) = ' & TimerDiff($start) & @TAB & ' GUIOnEventMode = ' & $n & @CRLF) ;### Debug Console
    ; Show the AutoIt3 hidden window
    WinSetState(AutoItWinGetTitle(), "", @SW_SHOW)
    $start = TimerInit()
    $x = 0
    For $i = 1 To 500000
        $x += 1
    Next
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : TimerDiff($start) = ' & TimerDiff($start) & @TAB & ' GUIOnEventMode = ' & $n & @CRLF) ;### Debug Console
Next
;~ -------------------------------------------- x86
;~ @@ Debug(21) : TimerDiff($start) = 62.6216    GUIOnEventMode = 0
;~ @@ Debug(29) : TimerDiff($start) = 327.3202   GUIOnEventMode = 0
;~ @@ Debug(21) : TimerDiff($start) = 440.6563   GUIOnEventMode = 1
;~ @@ Debug(29) : TimerDiff($start) = 440.1473   GUIOnEventMode = 1
;~ -------------------------------------------- x64
;~ @@ Debug(29) : TimerDiff($start) = 70.367     GUIOnEventMode = 0
;~ @@ Debug(37) : TimerDiff($start) = 200.1072   GUIOnEventMode = 0
;~ @@ Debug(29) : TimerDiff($start) = 333.702    GUIOnEventMode = 1
;~ @@ Debug(37) : TimerDiff($start) = 332.493    GUIOnEventMode = 1
;~ --------------------------------------------

 

Edited April 5, 2020 by argumentum
mistake

[jchd]

Here W10 Pro x64 v1909 OSversion 18363.752

Slowdown *6 on both x86 and x64 runs (compiled or not).

Fresh install + update (sorry, it's French):

Edited April 5, 2020 by jchd

[argumentum]

so it seem that the problem started with 1903 with the new light/dark theme concept.    Not it.

Edited April 5, 2020 by argumentum

[jchd]

That avalanche of diverging version formats, names, limitations, ... is a complete mess. $MS is known for messing its own stuff and that is getting worse over time.

I wonder what a complete release history of W10 + all of its updates + release notes of everything would look like!
 

[argumentum]

1803 it works fine.

1809 has those problems.  Fresh installed both.

[jchd]

18xx or 19xx? I'm lost

[argumentum]

up to 1803 is fine, 1809 onward is not.

Version 1803 (April 2018 Update)
Version 1809 (October 2018 Update)

Edited April 5, 2020 by argumentum
clarify a bit

[jchd]

If I understand Wikipedia W10 history well, that means the bug/issue was introduced by release 1809 (October 2018), 6 months after v1803 and 17 months ago, where all we can get today is v1909?

As a aside, latest "working" version is 1803 with end of support due May 12, 2020.

[argumentum]

..quite right @jchd. So there is no way around but to look at the issue.
The simple solution would be, a thread for gui and another for non-gui ( internally, not to bring mutithread to the product ), separating it, as to future proof the product.
( product = AutoIt ) 

But I'm not a programmer. All there is to do from now on, is wait for the Overlord   
On my side as a scripter, my solution is to fork the GUI away from the heavier stuff in the script, if I had a heavy script. ( my 2 cents )

In a new version, a build-in IPC would be very good to have ( request ) 

Edited April 6, 2020 by argumentum

[jpm]

6 hours ago, argumentum said:

up to 1803 is fine, 1809 onward is not.

Version 1803 (April 2018 Update)
Version 1809 (October 2018 Update)

So I think @Jon have to contact his old friends from Microsoft as he works for a long time ago with them.

[Danyfirex]

Hello. I did not notice this thread before. I got the issue under Windows 10 Pro N Version 1709.

I also get the issue after a Sleep call.

Issue with Running as x64 and x86.

#RequireAdmin does not reduce the issue to me.

 

Saludos

 

Edited April 19, 2020 by Danyfirex
Typos

[jchd]

59 minutes ago, Danyfirex said:

I also get the issue after a Sleep call.

Are you sure?  I can't reproduce that.

[Danyfirex]

 

@jchd Yes I'm sure. check gif. I also get the issue if I activate an external window like WinActivate("Untitled - Notepad")

Saludos

[jchd]

After looking closer, it appears it isn't exactly so.

Surprisingly, only the first loop is slowed down!  This is why you find such a difference.

expandcollapse popup

#include <Array.au3>

Func timeit()
    Local $x, $t = TimerInit()
    For $i = 1 To 500000
        $x += 1
    Next
    Return TimerDiff($t)
EndFunc

Local $Runs = 10
Local $n = $Runs + 4
Local $times[$n][4]

For $i = 0 To $Runs - 1
    $times[$i][0] = $i
Next

For $i = 0 To $Runs - 1
    $times[$i][1] = Round(timeit(), 1)
Next

Sleep(1000)

For $i = 0 To $Runs - 1
    $times[$i][2] = Round(timeit(), 1)
Next

For $i = 0 To $Runs - 1
    $times[$i][3] = Round($times[$i][2] - $times[$i][1], 1)
    $times[$n - 3][1] += $times[$i][1]
    $times[$n - 3][2] += $times[$i][2]
Next
$times[$n - 3][3] = Round($times[$n - 3][2] - $times[$n - 3][1], 1)

$times[$n - 4][0] = "====="
$times[$n - 4][1] = "======="
$times[$n - 4][2] = "======="
$times[$n - 4][3] = "======="
$times[$n - 3][0] = "Total"
$times[$n - 1][0] = "Average"
$times[$n - 1][1] = Round($times[$n - 3][1] / ($n - 3), 1)
$times[$n - 1][2] = Round($times[$n - 3][2] / ($n - 3), 1)
$times[$n - 1][3] = Round($times[$n - 3][3] / ($n - 3), 1)

Local $fRatio = Round(($times[0][2] / $times[0][1] - 1) * 100, 2)
Disp("First loop is", $fRatio)

$fRatio = Round(((($times[$n - 3][2] - $times[0][2]) / ($times[$n - 3][1] - $times[0][1])) - 1), 2)
Disp("Subsequent loops are", $fRatio)

$fRatio = Round(($times[$n - 3][2] / $times[$n - 3][1] - 1) * 100, 2)
Disp("Complete run is", $fRatio)

_ArrayDisplay($times, "Results", "", 0, Default, "Run #|Before sleep|After sleep|Difference")

Func Disp($s, $f)
    ConsoleWrite("" & StringFormat("%-20s% 6.2f", $s, Abs($f)) & ($f > 0 ? "% slow" : "% fast") & "er after Sleep()" & @LF)
EndFunc

The core really needs a serious review.  BUT, this particular slowdown may be due to resync within the OS multitasking scheduler granularity after a "long" sleep, even if I find the extra wait time a bit long.  Yet I think we can live with this as it doesn't seem to affect subsequent code significantly, if at all.  The permanent slowdown after window calls is much more severe.

Can you guys test under you own PC? and report?  (Run several times, as result vary)

I notice that the slowdown often vanishes when the Sleep() time is reduced to much lower values like 10, 20, 30.

Edited April 19, 2020 by jchd

[Danyfirex]

This is my ouput with your example:

First loop is        143.64% slower after Sleep()
Subsequent loops are  0.07% slower after Sleep()
Complete run is      20.85% slower after Sleep()

You're right, but If I have/need/put a sleep in my for It will slow down too. Check removing the sleep(1000) and add sleep(100) inside second for in your code like:

For $i = 0 To $Runs - 1
    Sleep(100)
    $times[$i][2] = Round(timeit(), 1)
Next

This is my ouput with the change above. 

First loop is        121.31% slower after Sleep()
Subsequent loops are  1.06% slower after Sleep()
Complete run is      107.12% slower after Sleep()

 

@jchd nice average code 👏

PD: Sorry If I'm not using syntax highlighting My 30Kbs connection don't want to load the required resource to use the syntax highlight feature.

 

Saludos

[jchd]

Replace Sleep(1000) by _Sleep(1000) to fix the issue:

Func _Sleep($ms)
    Local $t = _WinAPI_GetTickCount64() + $ms
    Do
    Until _WinAPI_GetTickCount64() >= $t
EndFunc

Restrict use to short values to avoid melting silicon down!

[water]

With Sleep I get for 5 runs on Windows 10 1803:

First loop is        34.87% faster after Sleep()
Subsequent loops are  0.05% faster after Sleep()
Complete run is       9.35% faster after Sleep()

First loop is        32.78% faster after Sleep()
Subsequent loops are  0.08% faster after Sleep()
Complete run is      11.84% faster after Sleep()

First loop is        52.93% faster after Sleep()
Subsequent loops are  0.05% faster after Sleep()
Complete run is      14.68% faster after Sleep()

First loop is        52.72% faster after Sleep()
Subsequent loops are  0.07% faster after Sleep()
Complete run is      16.25% faster after Sleep()

First loop is        38.24% faster after Sleep()
Subsequent loops are  0.05% faster after Sleep()
Complete run is      10.49% faster after Sleep()

With _Sleep I get:

First loop is        28.79% faster after _Sleep()
Subsequent loops are  0.05% faster after _Sleep()
Complete run is       8.00% faster after _Sleep()

First loop is         3.01% faster after _Sleep()
Subsequent loops are  0.03% slower after _Sleep()
Complete run is       2.71% slower after _Sleep()

First loop is        16.46% faster after _Sleep()
Subsequent loops are  0.03% faster after _Sleep()
Complete run is       4.91% faster after _Sleep()

First loop is        23.91% faster after _Sleep()
Subsequent loops are  0.03% faster after _Sleep()
Complete run is       5.82% faster after _Sleep()

First loop is        29.79% faster after _Sleep()
Subsequent loops are  0.12% faster after _Sleep()
Complete run is      13.76% faster after _Sleep()

 

[Danyfirex]

@jchd _Sleep(1000) remove the Issue but I think is more like a patch rather a full solution. ( of course because the solution will be change something inside AutoIt 😕)

 

Saludos