Your results varied from mine after you switched from a completely unambiguous
a > b to the very ambiguous
a == b. This is the ambiguity caveat I mentioned, not a change in the speed in which the parser handles IF conditions themselves. Consider the following condition (formatted to be completely unambiguous in every way):
if (
%a == 0 join #me) { myalias }
Removing the () or the { } can certainly cause unexpected results. If %a happens to equal 0, then you will try to join #me with a key of myalias, rather than checking to see if %a contains the string "0 join #me" and then executing myalias. By the same token, if %a happens to contain the string "0 join #me", then you will execute myalias. (This assumes mIRC will parse it correctly at all, something I would very much NOT like to ask it to do in my coding.)
Don't expect me to be surprised that it takes the parser longer to figure out where the condition ends and the command begins when you switch the test case condition to something ambiguous, such as
== or
isin. However, now we're no longer testing the relative speed of JUST the if condition parser, we're also testing how long it takes mIRC to parse ambiguous lines, as well. So, obviously, when you have qualified your condition with ( ), the parser will KNOW where to stop. And notice that this only affects the -() -{} test. The rest will be relatively unaffected, since they are all already qualified anyway.
