How Do You Test For Speed

Many of the more advanced JASS scripters test their scripts for time to test the speed for the scripts and make them faster so they don't kill threads (in extreme circumastances in most cases). Im just wondering wondering how exactly do you test for speed, is there some function that I don't know about or is it simply done mathematically. Here is just an example



The first function is obviously slower then the second, but how exactly would you test how fast the functions take to execute (in milliseconds or cycles)

There are two separate issues here: Speed and bytecode count. Grimoire can help you with both.
- jAPI.dll has stopwatch natives you can use for timing
- war3err.dll measures the op count of threads, keeps track of the max a map reaches and gives an onscreen notification if you exceed the maximum of 300,000

By default only war3err.dll is enabled. To use jAPI, remove the "--" in front of the injectdll("japi.dll") lines in we.lua and war3.lua and replace your map's script\common.j with the one provided in grimoire\jass\

Thanks, so you actually need to use dll injection to test for speed.

You don't have to, but it's the easiest way we have. The traditional method is with loops, TriggerEvaluate's and a wallclock.

I did that for ages, and believe me, it is darn inaccurate and tedious.

So this new way, how accurate is it? Enough to say one person's system is faster than another?

No, benchmarking is always 100% nonsense. I can't even imagine how I would go about benchmarking the vast majority of the systems out there. The most you can do is form personal biases and make educated guesses.

So why go through all the trouble :P

Speed can be incredibly important in some siutations. Im sure you have heard of game cache and from that ytou get attachable variables and dynamic arrays. Well basically for storing handle data attachable variables are the slowest because you call the H2I everytime you attach a variable. Using direct game chache is faster because you only call H2I once and store the integer as a string into a variable. Dynamic Arrays are propably the fastest way to store data in a 2 dimeansinal manner (including the H2I bug).

The point of me saying this is in the most practical way, a faster system can prevent threads being killed in the most extreme circumastances. For example if you want to move a unit 50 times at once to a different point each time and your using the H2I bug, if you used attachable variables the unit may only be moved around 20-30 times because it is not fast enough to be deemed instant. If you used dynamic arrays however since it is a lot faster the unit will be moved 50 times instantly.

This is just an example but it shows how speed can be very important when jassing


That must have been so annoying, i never thought that the first way to test for speed was so practical

The metric for killing threads is the number of ops executed. Calling a function is a single op; it doesn't matter how long it takes to execute.

The situation you suggest dynamic arrays for is probably better handled with something struct-like, with parallel arrays for each member. This is implemented in WeWarlock and JASSHelper. Dynamic arrays have a niche but it's not in replacing attached vars.

I like the location trick in vex's caster system, that is by far the coolest thing I've seen yet :P

well they are definitly faster then game cache but yes they are designed for the purpouse of what you have said. Honestly if you wanted to be incredibly fast you can just use a single variable array for the element your using the spell


lol, i still have no idea how linked lists work

location-based linked lists turned out to be the devil, due to the way they work they are extremely vulnerable to handle index corruption. And they are slower than dynamic arrays and way slower than structs anyways

Yes, but as far as creativity goes, it's #1!

Well using japi with the stopwatch natives worked without problems, thanks PipeDream