V3 Faster Than V2 ?

[wolf83 0]

just a question...

I was an user of autoit V2.64, is the V3 faster than the previous version ?

What is the improvment in % ?

thanks

Wolf

Edited February 26, 2004 by wolf83

[Chris_1013 0]

Isn't the technical term "balls out"?

[Bartokv 1]

I've noticed that the number of ticks to perform some functions are about the same in v2.64 vs v3.x. However, it also appears that other functions (math, string, etc related) are faster within v3.x. Overall, I'd say that it seems that v3.x is faster -- but due to the variance of speed per function, a general speed enhancement percentage would not be applicable.

[Jos 2,763]

just a question...

I was an user of autoit V2.64, is the V3 faster than the previous version ?

What is the improvment in % ?

thanks

Wolf

Save Hours of manual work and V3 has lots of extra Functionality.

Not really bothered if it takes 5000 ticks or 5010 ticks..

Edited February 26, 2004 by JdeB

[chamach 0]

AutoIt v3 is way faster when it comes to manage windows if you use the "Control" commands.

And if the v3 syntax is not as easy as the v2 one, the new functionalities talk for themselves : v3 is a lot better !

[cmallett 0]

But window searching and activation are often a lot slower with V3 because it uses the comprehensive method of detecting windows text. Most scripts won't be noticeably affected, but I have some that switch rapidly between different windows (such as for cut & paste operations) and that disappointed me, which was the reason for my original suggestion (many months ago) of making the "window search" method something configurable so that you could continue to use v2's fast method if you wanted.

[Bartokv 1]

Do we have a v3 nemesis?

It's definitely not me... I love v3!!!

Truth be told, I don't bother updating my old v2 scripts anymore -- just rewrite them in v3 when any edits need to be made... Makes later code mods a LOT easier!

Edit: Especially with the external UDF includes

Edited February 26, 2004 by Bartokv

[Jon 1,248]

But window searching and activation are often a lot slower with V3 because it uses the comprehensive method of detecting windows text.  Most scripts won't be noticeably affected, but I have some that switch rapidly between different windows (such as for cut & paste operations) and that disappointed me, which was the reason for my original suggestion (many months ago) of making the "window search" method something configurable so that you could continue to use v2's fast method if you wanted.

The test I used at the time that was mentioned:

With about 10 windows open and various tray icons including one browser window titled "HiddenSoft Forums"

; 15.2 secs WM_GETTEXT
; 16.4 secs GetWindowText()
$time = timerstart()
for $i = 1 to 16384
WinExists("HiddenSoft Forums", "kjfdjkhhkj")
next
msgbox(0, "", timerstop($time))

There didn't seem much point in changing it. Maybe it's slower for some apps *shrug*

[Jon 1,248]

Actually it changes alot depending on the compiler I was testing the VC6 WM_GETTEXT against the VC7 GetWndowText. When using the same compiler:

WM_GETTEXT = 19 secs

GetWindowText() = 16.4 secs

But still, that's 16384 operations...

[wolf83 0]

Yes V3 have a lot of function and i find the new syntax better too.

Very good job

Wolf

[cmallett 0]

The window search method is highly senstive to what types of apps are currently running. If even one of them is sluggish about checking its message queue (perhaps due to being busy doing a long disk operation), or is hung, window activation can suffer if the target window is beneath the sluggish window in the z-order. This is because the sluggish window may take up to 5 seconds to respond (at which point the operation times out), possibly resulting in extremely slow window searching and activations. At least, this was the result I was getting when I tested v3. It was very noticeable when running certain scripts and under certain conditions.

In short, the worst case performance of v3 windowing operations (5 second delay) is dramatically worse than the worst case for v2. But the average case doesn't suffer much.

[Jon 1,248]

It's a simple enough change, just a couple of lines so I'll add an option. I'll default to the comprehensive mode though. Now a name for the option, hmmm....

[cmallett 0]

Well, I did it with TitleMatchMode... "overloading" it to support the words "fast" and "slow". But you'd probably want some other method. Also, I modified Larry's Window Spy to report the "slow" text in a different section.

I've yet to find a window for which I need the slow mode, but I'm sure there will be a need on rare occasion.

[Jon 1,248]

Well, I did it with TitleMatchMode... "overloading" it to support the words "fast" and "slow".  But you'd probably want some other method.  Also, I modified Larry's Window Spy to report the "slow" text in a different section.

I've yet to find a window for which I need the slow mode, but I'm sure there will be a need on rare occasion.

Anything with a text control.

For instance, you can do

WinWait("Untitled", "this is a word")

And that will only match the untitled notepad editor when you type "this is a word".

I use it loads in my autoit build script as well for determining when VC has finished a build or HTML workshop has completed because one of the windows has a "Compilation complete" bit of text.

I could never do that in v2. Of course when I add the option to v3 I could find that it didn't work in v2 for other reasons and was nothing to do with WM_GETTEXT