Sign in to follow this  
Followers 0
vdo

~15% CPU Usage on Simple WinWait

12 posts in this topic

#1 ·  Posted (edited)

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 by vdo

[center][font="Tahoma"]What are all those clowns following me for?[/font][/center]

Share this post


Link to post
Share on other sites



Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

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 by Inverted

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by KaFu

Share this post


Link to post
Share on other sites

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


Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

@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

Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by Valik
Re-worded some stuff.

Share this post


Link to post
Share on other sites

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


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

@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 by herewasplato

[size="1"][font="Arial"].[u].[/u][/font][/size]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0