~15% CPU Usage on Simple WinWait

[vdo]

Reference to a similar problem (an old thread):

http://www.autoitscript.com/forum/index.ph...amp;hl=CPU+high

From that thread:

I've had this problem too - around 10-15% CPU utilisation which is way too high. The workaround works - but the function shouldn't chew up the CPU this way in the first place...

I'm Currently getting the same CPU consumption on a WinWait...without the PF Delta issue, though. Anyone know what's the diagnosis?

@Anybody on the Devel team:

...is there an explanation in the WinWait & ProcessWait code for these results?

(Sorry I haven't downloaded the AutoIT source to look at it...too busy right now working

on this release, but I'm at a loss with the ~15% CPU usage on a WinWait...)

I'd rather not use the kludged solution in the prior post, though I have to

admit haven't tried it either...but may need to resort to it if a real answer to what ails

me is not found soon.

Thanks for any response.

Edited June 16, 2009 by vdo

[KaFu]

Hmm, cant reproduce... but what happens, if you add a sleep(10) at top of each of the two while loops?

[Inverted]

I can't reproduce either. I tried a simple one-liner : WinWait ("Untitled")

Compiled the script, checked the CPU time, it's seemingly always at 0. And it works correctly of course.

I'm on XP sp3, maybe it's OS-related ? Can you do this one-line test also, OP ?

Edited May 29, 2009 by Inverted

[KaFu]

Maybe add a sleep(0)? Search forum for special behavior of this one... btw. 10 ms is so close to immediate, a human will never see the difference. What kind of impact do you expect from gaining 10 ms in reaction speed?

Edit:

Also try what effect the change of the default value of Opt("WinWaitDelay", 250) has on you script.

Edited May 29, 2009 by KaFu

[Jos]

I can only assume that both the Window exists and the program is running which would give you a High cpu.

Post a script we can run that reproduces your problem when you want us to have a look at it.

Jos

[Jos]

@Jos, Your assumption is correct...both programs ARE almost always running,

but why should the CPU be high because of that? Would it not be mostly in a noop

until the window that xyz throws up appears? (Every 20 seconds, being the exception).

Unless I'm mistaken, the WinWait timeout is in seconds, right? Thanks for responding.

My assumption was that the Window exist and the process.

When that is the case it will be constantly looping Inside the first While Wend performing the ReduceMemory() back to back without any Sleep()

While ProcessExists("xyz.exe")
    If WinWait("window - title xyz", "", 20) = 1 Then; Window Appears
        .
        .
        If $Good Then
            .
            .
        EndIf
    EndIf
    ReduceMemory(@AutoItPID)
WEnd

[Valik]

The result is: CPU ~ 5-25% (roughly averaging 15%)... that's it.

Apparently the code around matching window names (and Process Names) is not

very efficient, and particularly lowercase matching...

Yes, because clearly you are incapable of making a mistake and we are a bunch of incompetent buffoons, right?

Sorry, but no. Your claims are unfounded. I'm more inclined to believe this is your fault with your code. For example, I see shoddy lines like this:

IF WinWait("window - title xyz", "", 20) = 1 Then

Never hard-code a test like that. Ever. It's bad code and it will break if you use beta 3.3.1.1 because the return value of WinWait() has changed.

I see other bad things such as the call to ReduceMemory(). If that function does what I think it does then you shouldn't even be using it. Arbitrarily reducing the working set of the process negatively affects process performance more than it helps system performance.

In short you have demonstrated no reason for anybody to think it's a bug in AutoIt and have demonstrated several reasons to think it's just bad coding on your part. You do not prove your claims with your code and in fact demonstrate several (unrelated) issues in your code. I think you need to look at your own code before you start criticizing ours.

Edited May 30, 2009 by Valik
Re-worded some stuff.

[trancexx]

Opt("WinSearchChildren", 1) is causing this.

[Valik]

Opt("WinSearchChildren", 1) is causing this.

That makes some sense since it causes AutoIt to do several times the amount of work. On my system it's 3x. I would expect an order of magnitude is easily possible depending on the type of programs being run. For example, just opening a single instance of Visual Studio caused a significant change in the number of windows on my system. It added ~100 top-level and ~275 child windows.

I won't say the code for finding windows can't be optimized some but under the circumstances it's not going to hit a low CPU usage. The operation is done in linear time with no match being the absolute worst-case and most common scenario in the code as written. Any reason more windows are added into the search pool the longer it's going to take, period.

[Valik]

Please expound... there are no child windows open during this CPU "situation"

You don't actually know what that option does, do you? Run this, maybe it'll click:

Local $a = WinList()
Local $nTopLevel = $a[0][0]
ConsoleWrite("Top-level: " & $nTopLevel & @CRLF)
Opt("WinSearchChildren", 1)
$a = WinList()
ConsoleWrite("All: " & $a[0][0] & @CRLF)
ConsoleWrite("Child: " & $a[0][0] - $nTopLevel & @CRLF)

[KaFu]

My help shows WinWait timeout is in seconds. If this is actually ms, then there's the answer...

You're right , normally win operations are in ms, but this Wait functions aren't. Hmmm what about changing the overall logic? I guess you can achieve the same result with a much tighter WinExists() loop. This will at least preserve the responsiveness of the script and also should reduce CPU usage to 0% if you include a Sleep(10).

[herewasplato]

@KaFu,

The more windows that you have open the harder the task of watching for a window match.

If you run these three lines, you might see some minor CPU loading:

Opt("WinTitleMatchMode", -3) ; Exact Match Mode (lowercase)

Opt("WinSearchChildren", 1) ; Search Child Windows, too

WinWait("untitled - Bogus Is My Name","")

If you leave that code sitting there on the WinWait and you open up an app like Valik mentioned - Visual Studio, then you should see an increase in the work that the CPU has to do because it now has more windows to search thru.

With this Opt line...

Opt("WinTitleMatchMode", -3)

...you increase the workload.

With this Opt line...

Opt("WinSearchChildren", 1)

...you increase the workload even more.

The WinWait code searches (< CPU load) for a match and then sleeps for about 10ms.

http://www.autoitscript.com/forum/index.ph...st&p=676849

You suggested replacing WinWait with something like:

Do

Sleep(10)

WinExists(......

That loop does about the same loading of the CPU since WinExists still has to search thru all of the window titles.

Edited May 30, 2009 by herewasplato