Is there a way to reduce AutoItX time overhead?

[lgodfrey]

If one runs a typical AutoItX function from within code such a Excel VBA, such as WinGetText, it takes about twice as long as the same function call from code being run from Scite, and almost 3 times slower if run from the compiled versson of the script. The latter I can understand (ie the compiled version running faster than from within Scite), and the fact that there is more overhead running inside VBA I can understand. But a 2X time hit seems excesive (25 msec vs 12 msec for the WinGetTxt on my 3Ghz P4.)

The WinWaitDelay setting is at its default value of 250 msec, so it would not appear to have anything to do with this time difference.

I am fishing for ways to cut down on the time overhead withing VBA. Is there a way to "keep the connection live" between AutoITX and VBA so that AutoITX is always "ready" for the call from VBA?(this is a pure guess question on my part, ie I am guessing VBA needs to "re-open an AUtoITX channel" for every call to AutoITX). Sorry I do not know the right technotalk for this concept.

Does a multi-processor machine handle this time issue better than a single core processor?

Any suggestions how to reduce this time significantly?

Best regards, Larry

[MHz]

Does a multi-processor machine handle this time issue better than a single core processor?

Unless you program to make use of >1 CPU, then I would consider NO. The debate of quad core CPUs (which the OS sees as >1 CPU) is that they are not recognized by most applications as utilizing no more then 2 of the cores as the programs are not made in account of quad core. 2 separate CPU's would fall under similar issues IMO as multi-core CPUs.

Any suggestions how to reduce this time significantly?

You did mention Opt() so would test with tweaking options to see if you get reasonable results before asking for AutoItX source changes. I would expect variations depending on which programming language you used so AutoItX source changes would have to be justified on strong grounds on this consideration.

[lgodfrey]

Thanks for the feedback, MHZ.

I have done some more timing testing, and the two items that seem to be quite long are the WinGetText and the Send methods. Control specific methods like ControlGetText and ControlSend work about 10X faster.

Since I have several WinGetText/Send's in my current code which take up far too much time, my workaround is now to never use these unless absolutely necessary. If I can't use control methods, then I have set up a AutoIT program that performs the send and get at 3X the speed of the same code in VBA, and then put the info into a splash window. VBA uses a control method to get the info from the splash window rather than using a WinGetText to get the info from the window directly. THis is ugly, but much faster. You have to be carefull about the asynchronous aspects of this info transfer. It also has the advantage of working on different threads, so it gets a speed boost if used in multi-core/processor machines.

However, I am still hoping there is a more elegant way of reducing the over-head inside the VBA code that someone might be able to tell me about. I haven't been able to find a Opt() setting that helps.

[MHz]

I haven't been able to find a Opt() setting that helps.

Look at the 2 Opt() settings with trailing asterisks as they govern WinWait delay and speed that each character is sent with Send().

' Mouse Options
Opt "MouseClickDelay", 1            ' 10 milliseconds by default.
Opt "MouseClickDownDelay", 10       ' 10 milliseconds by default.
Opt "MouseClickDragDelay", 25       ' 250 milliseconds by default.

' Send Options
Opt "SendKeyDelay", 1               ' 5 milliseconds by default.*****
Opt "SendKeyDownDelay", 1           ' 1 millisecond by default.

' Win Options
Opt "WinWaitDelay", 25              ' 250 milliseconds by default.*****

The others above can help with speed also if suitable functions are used. Those are the major Opt()s to change for speed up.

[lgodfrey]

I haven't been able to find a Opt() setting that helps.

Sorry, should have been more specific, I have not been able to find an Opt() setting that helps with the slow AutoITX time compared to the faster AutoIT time. Setting SendWaitDelay to 1 msec did help both a little (about 20% so the time is just under 20 msec for VBA now for the Send method, no change for the WinGetText).

I did find a reference that said "early binding can improve performance". The examples were aimed at binding office objects, not general objects, so I am over my head on this concept. Here is how I implement AutoITX in vba as an example (this I think is late binding).

Public oAIX As Object
Set oAIX = CreateObject("AutoITX3.Control")
bSuccess=oAIX.Send("^A")

From this new reference, this "late binds" AutoITX to the code, ie it only does the binding when the createobject code line is executed, not when the code is compiled. It looks like to early bind, you have to be more specific on the declaration of the object. With the extra info, I guess the binding can take place at time of compiling. Here is an example given:

Public xlApp As Excel.Application
Set xlApp = CreateObject("Excel.Application")

My guess is that the equivalent version of AutoITX is:

Public oAIX As AutoITX3.Control
Set oAIX = CreateObject("AutoITX3.Control")

This gives a compile error on the public dim statement that "User-defined type not defined".

So, .... do you think early binding will help with the speed disparity? Any idea how to do it in VBA (Am I at least on the right track so I should spend some time on a VBA forum to find out more?)

[daluu]

The VBA code mentioned here, is that run from within an MS Office application? Or from Windows Scripting Host (WSH)?

I'm just wondering if there is a performance difference between these two. I don't use VBA and I don't use much of the AutoItX functions but the ones I've used work pretty fast under WSH.

I've used Send, WinActivate, WinWaitActive, MouseClick, and AutoItSetOption.

I wonder if there is also a performance difference when executing under ASP web script, although most people wouldn't use that.