Long variables increase lag, JASS is not pre-compiled.

Okay, I have TESTED it. Results are HIGHLY CONCLUSIVE that longer variables can indeed cause more lag, using the simplistic example like this:
And then calling it 2000 times.

This took ~4.4 seconds to run.

I then replaced the "i" with a long string, about 250 characters long.
Running again, it took ~30 seconds to run, a 7fold increase.

As simplistic and contrived the example may be, it does conclusively prove that JASS is not pre-compiled into any form of "bytecode" and is indeed interpreted on the fly. While the effect of long variables may not be noticeable in general triggering (where the natives themselves take a while to run), the effect of long variables could be noticeable in number crunching applications [but the variables could probably only grow significantly long enough using map protection that makes long variables]. Possibly more interesting at least academically is the proof that the script isn't pre-compiled when the map loads.

very nice work! Its obvious that the script isn't precompiled when you look at what a War3 map actually is. But no idea that a variable length could decrease the speed at which the program executed.

Actually no, because blizzard could just preffer to have a script there and compile it in the loading (they wouldn't add a builtin map protection method), that is why this is considered a discovery.

Wow, this is a rather sad discovery =-/

Apparently the creators of Jass couldn't even be bothered to finish reading a good compiler book. The one I have now gets you this far about 1/4 of the way through the book.

"Better luck next time" or something like that, Blizzard. I wonder if they use Jass in WOW or if they've fixed it and made Jass2 or something.

JASS is actually already JASS2, and they don't use JASS in WoW, but Lua. Which they didn't program themselves. Guess they learned their lesson huh :)

We know that the script is parsed at the beginning of the map as any script errors are recognized then. So why the hell would they discard that and repeat it often on runtime ?
How exactly did you call that function ?

Aiandy, that may be true but I have to remind you that ALOT of things are done very stupidly in war3.

It is possible to crash warcraft by simply clicking on a map in the custom map loading screen that contains a faulty script. Thus, it is unlikely the script is not compiled at load time as it would be odd for a parser to crash the entire game?

Try passing real values as colors into the 'SetCineFilterStartColor' native.

The parser Warcraft uses has some bugs that can cause crashes on faulty scripts (a common problem when writing JASS in WE).

It may be that there is no address computation and resolution done on compilation and the values of variables are kept in hashes and looked up by the variable name. There is one thing that does not fit then though and that is the bug that 2 local variables with different names that each have the same name as a global become aliases of each other.

I think this could explain some stuff like execute func, or the lack of estrutures different than if then else and loops. Likelly Select case, labels and goto, native for loops, and how it is not possible to pass variables as arguments, and that stuff.

The return bug also works for 'code' which seems to imply that functions are assigned a handle the first time the script is parsed.