StopWatch (speed benchmark) natives (1.24c)

07-26-2009, 08:05 PM

If you want to measure how long it takes for a block of Jass code to execute, this is what you're looking for.

This will only work with version 1.24.4.6387.

Natives added:

JASS:

native StopWatchCreate  takes nothing returns integer
native StopWatchMark    takes integer stopwatch returns real
native StopWatchDestroy takes integer stopwatch returns nothing

See the sample (map.w3x) included in the archive to find out how they're used.

To use the natives in a map, add the common.j from the archive using the import manager and make the path scripts\common.j. Then you can use the natives like any other. You probably need NewGen in order to save the map (make sure the WE syntax checker is disabled).

Two (main) ways of injecting it to Warcraft III:

Copy war3.lua and stopwatch.dll to your NewGen directory (where NewGen WE.exe is located), replacing the original war3.lua in the process (you'll probably want to make a backup first). Then you can use NewGen Warcraft.exe to run WC3 with the natives injected. Hopefully Mindy will also bring back the "Start war3 with grimoire" option to NewGen so you could use it to test maps quickly.
Use the included inject.exe.
Syntax: inject.exe <path to stopwatch.dll> <war3 parameters>
Example: inject.exe C:\myfolder\stopwatch.dll -window

Credits:

PipeDream - the 3 StopWatch natives inside stopwatch.cpp are actually copied from grimoire.
xttocs for iat.cpp which I used on many occasions.
MindWorX for working with me on RtC & asking me to make this.

Feel free to ask questions & report bugs.

Source distributed under the GPL. Compiles using MinGW with the command g++ -shared -o stopwatch.dll main.cpp stopwatch.cpp iat.cpp CLogger.cpp.

I except to see some speed benchmark on the new hash natives soon!

Attached Files

	stopwatch_0.3.2.zip (134.9 KB)
	stopwatch_0.3.2_src.zip (4.4 KB)

07-26-2009, 08:08 PM	#2
Tyrande_ma3x	Awesome... I'd really like to see a speed test on the hashtables as well.

07-27-2009, 09:52 AM

akolyt0r

have done a quick bench ...
since im lacy i used Vex's Table for it (old GC version versus new Hashtable version)

Hidden information:

rough conclusion:
Hashtables are a LOT faster for SET operations, and 2-3 times faster for all other operations

Attached Images

	WC3ScrnShot_072709_114732_01.jpg (52.5 KB)
	WC3ScrnShot_072709_115045_01.jpg (50.0 KB)

07-27-2009, 11:13 AM

Toadcop

Quote:

I except to see some speed benchmark on the new hash natives soon!

and also some fatals while flushing it *blizz*

08-01-2009, 07:37 AM	#5
masda70	While we are it, can someone compare basic array operations in 1.24 and before 1.24? I remember from my manual benchmarking (with a physical watch) that 1.24 was slower on existing operations in general. The hashtable vs gamecache results do concur with my older tests though.

08-12-2009, 04:14 PM

Tom Jones

Now, would updating this be as simple as changing this;

Code:

// these are the three addresses that should be changed when a new version comes out
// current version: 1.24.0.6366
pjInitNatives jInitNatives = (pjInitNatives)0x6F454760;
void *InitNatives_patchpos = (void*)0x6F3D4B11;
pjBindNative jBindNative = (pjBindNative)0x6F455C70;

to the correct values and recompiling? I'm guessing it's not.

08-12-2009, 04:40 PM	#7
Alevice	If that's the case. I wish those damn addresses were accessible vi a simple ini file or smth.

08-12-2009, 08:01 PM

MindWorX

Quote:

Originally Posted by Tom Jones

Now, would updating this be as simple as changing this;

Code:

// these are the three addresses that should be changed when a new version comes out
// current version: 1.24.0.6366
pjInitNatives jInitNatives = (pjInitNatives)0x6F454760;
void *InitNatives_patchpos = (void*)0x6F3D4B11;
pjBindNative jBindNative = (pjBindNative)0x6F455C70;

to the correct values and recompiling? I'm guessing it's not.

It actually is, tho finding the new addresses might prove harder. But we're working fast on a new RtC release, should include stopwatch with it.

Quote:

Originally Posted by Alevice

If that's the case. I wish those damn addresses were accessible vi a simple ini file or smth.

Interesting you should say ini, the next RtC is updateable through an ini file :P

08-12-2009, 10:50 PM	#9
SFilip	Code: // 1.24.0.6372 pjInitNatives jInitNatives = (pjInitNatives)0x6F4546F0; void InitNatives_patchpos = (void)0x6F3D4AA1; pjBindNative jBindNative = (pjBindNative)0x6F455C00; Enjoy. If anyone feels like compiling and posting the new version, feel free to do so. Otherwise I'll do it in a couple of days when I come back.

08-13-2009, 12:25 AM

#10

Earth-Fury

Completely untested. CnP'd SFilips new addresses and compiled with MinGW. Zip includes only the DLL. Took 5 seconds to do. Post if you try it.

Attached Files

stopwatch.7z (18.9 KB)

08-17-2009, 07:44 AM

#11

Tom Jones

Quote:

Originally Posted by Earth-Fury

Completely untested. CnP'd SFilips new addresses and compiled with MinGW. Zip includes only the DLL. Took 5 seconds to do. Post if you try it.

Works like a charm.

08-17-2009, 08:29 PM

#12

Troll-Brain

Does someone plan to make valids benchmarks (extended)arrays vs Hashtables ?

Here is a short one :

JASS:

library HashtableTests initializer init 

globals
    private integer array I[10000]
    private hashtable H
    private real T0
    private real T1
endglobals

private function Actions takes nothing returns nothing
    local integer sw = StopWatchCreate()
    local real t0
    local real t1
    local integer i = 7000
    local integer x = 1
    set t0 = StopWatchMark(sw)
    
    loop
        exitwhen i>=10000
        call SaveInteger(H,0,i,i)
        set i = i + 1
    endloop
    set t1 = StopWatchMark(sw)
    
    set T0 = 1000*(t1-t0)
    call BJDebugMsg("hashtable set done ; i == " + I2S(i) + " ; " + R2S(T0))
    
    call TriggerSleepAction(0.)
    
    set i = 7000
    set t0 = StopWatchMark(sw)
    
    loop
        exitwhen i>=10000
        set I[i] = i
        set i = i + 1
    endloop
    set t1 = StopWatchMark(sw)
    
    set T1 = 1000*(t1-t0)
    call BJDebugMsg("array set done ; i == " + I2S(i) + " ; " + R2S(T1))
    call BJDebugMsg("hastables are " + R2S(T0/T1) + " times slower than array")
    call StopWatchDestroy(sw)
endfunction

private function init takes nothing returns nothing
    local trigger trig = CreateTrigger()
    call TriggerRegisterPlayerChatEvent(trig,Player(0),"set",true)
    call TriggerAddAction(trig,function Actions)
    
    set H = InitHashtable()
endfunction

endlibrary

It displays that hashtables are only about 0.5 time slower with this kind of extended array, and only about 1.5 time slower vs a not extended array.

Yes i know i don't flush and so one, it's just a short test, pending much more valid and complete tests, read/flush, ...

So it seems they are pretty fast, aren't they ?

08-17-2009, 09:13 PM	#13
BlinkBoy	weird, I benchmarked normal array vs Hashtables and hashtables did 0.0078 while arrays did like 0.0044.

08-18-2009, 03:41 PM

#14

Troll-Brain

Quote:

Originally Posted by BlinkBoy

weird, I benchmarked normal array vs Hashtables and hashtables did 0.0078 while arrays did like 0.0044.

And why it's weird ?
0.0078 / 0.0044 = hashtable 1.77 times slower than normal array.

08-20-2009, 12:12 AM	#15
Rheias	Any reason why this should not work? I copied war3.lua and stopwatch.dll and common.j to NewGen's folder. No good. I tried injecting, the injecting software doesn't run. I tried downloading Earth-Fury's update and using the new dll file, still no good. Whenever I try to use one of these function I get syntax error stating that function is undeclared... Thanks for any help/