I've once heard that it should work, however I've never personally tested it, neither have I ever been comfortable using it. However if it works you cant get a faster native alternative. I'll log on later and test it out.would cause desynchs in multiplayer maps. I don't feel like testing if it would cause desynchs. Let me know if it doesn't.
If those results are irrelevant I don't understand why you posted them in the first place.I'll repeat that one test with the exact same BJ inlined immediately. Obviously it has no impact on the other test whatsoever. Of course, this test is irrelevant in the first place. -.-
You aint never going to make me feel silly about questioning either your results or methods.But before I go run this test, I need to make you feel a little silly for making me do it...
I remember that there was some reason why you should not use it. ( Gotta check wc3c , I dont quite remember )I've once heard that it should work, however I've never personally tested it, neither have I ever been comfortable using it. However if it works you cant get a faster native alternative. I'll log on later and test it out.
Ok, to make this any clearer... I triggered 50 triggers on when ability 'A00F' is cast (doesn't actually exist, just to add the effect of having 50 abilities in the map) and 1 trigger fired off when Phoenix Morph was cast (by cast I mean SpellEffect). This means when I call KillUnit on any Phoenix, all 51 triggers fire immediately. I can therefore time that Kill action, and compare it to if I implemented the same stuff using GTrigger. Of course, it has the overhead of the Phoenix turning into an egg and such, but that's not important, because it is assumed to be constant.In case you're wondering how I tested the firing, there's a spell that fires IMMEDIATELY on unit death (as in, if you call KillUnit, the triggers for that spell will fire before the next line of code is run), and that's Phoenix morph. So I simply registered 50 abilities on that spell effect, then started a stop watch, killed a phoenix, and clocked the stop watch. Each test repeated this 50 times, and I repeated each test about 5 times. I then reduced that 50 to 20, still being slower I reduced it to 5, then 2, then 1 failing trigger and 1 working trigger (both attaching using conditions only). Quite a reliable, appropriate test.
Just to clarify that, all triggers in my bench test attached with a single condition only.
globals private filterfunc non_leaking_filter = null endglobals private constant function DummyFilter takes nothing returns boolean return TRUE endfunction set non_leaking_filter = Filter( function DummyFilter ) call TriggerRegisterPlayerUnitEvent(whichTimer, whichPlayer, whichEvent, non_leaking_filter)
That, added to the fact every event is processed through this system, will effectively create a boolexpr table best suited for its purpose.Dark_Dragon said:boolexpr is like a table with condition you typed ~via Filter() or Condition() well since script does not know what pointer null is since it will not have table, the leak in memory is created because it will allocate something because you typed null and that something is some part of memory which can contain some data as well but will never again, until you leave the game. So the only thing you have to do is a valid boolexpr table, in your case it should only do nothing (no condition) in trigger registration so do it like next:
we must NOT destroy that filter and we can use that filter unlimited number of times you don't have to make it private if its in your map.
hm..?Add AnyUnitDies style event.
If you have loads of globals, it slows them all down. But yea, its probably still faster.Why don't I just use locals? Because deep down, my belief is if it's easy to make more efficient, do it. Initializing a local and setting it takes twice as long as setting a global.