Registering Events

[Alain.Mark]

Will registering a lot of events into a single trigger slow it down? :O

 

[shinji]

I don't think it will slow down. I have once made a trigger with 10 events but I didn't notice any slowness.

 

[Alain.Mark]

how about 200+ events?

 

[overcold_ice]

i think it depends on what the events are . . . .

 

[Cokemonkey11]

What is your trigger?

Are you dynamically allocating events?

200 events in a single trigger is quite fine if it's a static, map initialized trigger.

 

[Alain.Mark]

oh okay, it's for a damage detection trigger (just for testmaps tho XD)

 

[Cokemonkey11]

If you are indefinitely using CreateUnit() then the game will crash when the trigger reaches its event cap.

There are ways around this if you're not recycling units though.

 

[Troll-Brain]

A trigger has an event cap ?!

I mean you experienced it or it's just a theory ?

 

[Cokemonkey11]

I've experienced it, yes. I still have the map in which a script of mine first encountered it but I'm a bit lazy to test it again now.

http://filesmelt.com/dl/4AvalancheWithDDKB006.w3x

good damage detection systems don't let the event cap be reached by means of a few different methods.
-unit recycling
-individual triggering
-stack based with event counts and isAlive checks

 

[shinji]

Hmm... But I think if it doesn't crash it won't slow down right?

 

[Cokemonkey11]

that's correct iirc

 

[Arhowk]

Your triggering EVERY UNIT INTO A DAMAGE DETECTION SYSTEM? *cough*soinefficientandtimewasting*cough*

 

[Alain.Mark]

*cough*itsforatestmap*cough* for stress testing.

 

[Cokemonkey11]

Your triggering EVERY UNIT INTO A DAMAGE DETECTION SYSTEM? *cough*soinefficientandtimewasting*cough*

Not really. As long as you don't break the event limit, this is more efficient than individual triggers.

 

[overcold_ice]

can you give me the event limit number ?
it will really helps ^_^

 

[Cokemonkey11]

I don't know the limit but if I had to guess I'd say it was somewhere around 8,192, similar to maximum array index.

Additionally, I don't know what happens to the event registration if the unit is removed.

 

[Magtheridon96]

Every single resource using RegisterPlayerUnitEvent, GTrigger and RegisterAnyUnitEvent will have to be rescripted if this is true >:l

(Depending on the event cap)

I'm going to look into it and find the exact number.

 

[Cokemonkey11]

Let me know what you find out. My guess is that the real number is simply too high to realistically be reached in a normal game.

 

[Magtheridon96]

I'll post the results in this post

I was going to find out the number, but then I got distracted and coded a new resource instead D)

I'm getting back to finding the cap now =p

edit

So far:
Simple registeration: >10000

edit

1 trigger + 1300 event registrations + firing the event = NO lag.
I'm going to try this while registering boolexprs to the trigger ;D

edit

Wow, even with an empty boolexpr, nothing.
With a boolexpr that prints text, nothing.

With a CreateUnit call, *testing* it froze and crashed T_T (with 7820 registerations)
With 1300: 2 second lag spike.

We have nothing to worry about
The number is too high for anyone to test for ;D

edit
Did another to test to get the event cap.
With a 0.001 timer, I was able to register 38000 events with 0 lag (very minor FPS drop that I couldn't notice)
Then, at 40000, it began to lag a bit.
At 50000, it lagged even more.
I gave up at 70000 because it was way too laggy :/

 

[Cokemonkey11]

regarding that last edit - the final test began to lag by creating events without even creating more units?

I think 70,000 is far beyond the scope I was dealing with in my system.

 

[Magtheridon96]

The final test involved no unit creation
Only 2 of my tests involved unit creation :>

With a CreateUnit call, *testing* it froze and crashed T_T (with 7820 registerations)
With 1300: 2 second lag spike.

 

[Alain.Mark]

Thanks for the info mag. =)

 

[Troll-Brain]

I'm wondering if the result wouldn't be the same or maybe even worse with X triggers which have one event.

Btw Mag, i don't how how you did the tests but if you had the very same event X times to a trigger it will fire the trigger X times when this event fire.
You should probably know that but i find a bit weird your sentences :

The final test involved no unit creation
Only 2 of my tests involved unit creation :>

 

[Magtheridon96]

Ok, my tests were flawed, so I did them again.

What I did:

struct Test extends array
    
    private static trigger onDamageTrig = CreateTrigger()
    private static trigger damageUnitsTrig = CreateTrigger()
    
    private static integer requiredOperations = 8200
    
    private static Table u
    
    private static integer count = 0
    private static integer index = 0
    
    private static method causeDamage takes nothing returns boolean
        local integer op = 200
        loop
            call UnitDamageTarget(u.unit[requiredOperations], u.unit[requiredOperations], 60, false, false, null, null, null)
            set op = op - 1
            set requiredOperations = requiredOperations - 1
            exitwhen op == 0 or requiredOperations <= 0
        endloop
        return requiredOperations <= 0
    endmethod
    
    private static method onDamage takes nothing returns boolean
        set count = count + 1
        return false
    endmethod
    
    private static method createUnits takes nothing returns nothing
        call CreateUnit(Player(0), 'hpea', 0, 0, 0)
        if index == 8200 then
        
            call BJDebugMsg("dealing damage")
            call PauseTimer(GetExpiredTimer())
            call DestroyTimer(GetExpiredTimer())
            
            loop
                exitwhen TriggerEvaluate(damageUnitsTrig)
            endloop
            
            call BJDebugMsg("dealt damage")
        endif
    endmethod
    
    private static method display takes nothing returns boolean
        call DisplayTimedTextToPlayer(GetLocalPlayer(), 0, 0, 60, I2S(count))
        return false
    endmethod
    
    private static method onEnter takes nothing returns boolean
        set index = index + 1
        set u.unit[index] = GetTriggerUnit()
        call TriggerRegisterUnitEvent(onDamageTrig, u.unit[index], EVENT_UNIT_DAMAGED)
        return false
    endmethod
    
    private static method onInit takes nothing returns nothing
        local trigger t = CreateTrigger()
        local region r = CreateRegion()
        set u = Table.create()
        call RegionAddRect(r, GetWorldBounds())
        
        call TriggerRegisterEnterRegion(t, r, null)
        call TriggerAddCondition(t, Condition(function thistype.onEnter))
        
        call TriggerAddCondition(onDamageTrig, Condition(function thistype.onDamage))
        call TriggerAddCondition(damageUnitsTrig, Condition(function thistype.causeDamage))
        
        set t = CreateTrigger()
        
        call TriggerRegisterPlayerChatEvent(t, Player(0), "-", true)
        call TriggerAddCondition(t, Condition(function thistype.display))
        
        call TimerStart(CreateTimer(), 0.001, true, function thistype.createUnits)
        
        set r = null
        set t = null
    endmethod
    
endstruct

This didn't bug.
It displayed 8200, meaning that all the events were correctly registered.

(I chose 8200 because it's just above 8192)

This event cap must be pretty high :l
(Maybe 65536)

 

[Troll-Brain]

Honestly i think the only limit is the limit of the ram.
Also i have never tested it but many people say that more handles id leak you have, more the jass vm is slow.
And i suppose an event make one, even if the unit is removed later (i have not tested it)

 

[Magtheridon96]

An event should be nothing but an integer that points to a stack of triggers
And a trigger should be nothing but an integer that points to a queue of triggeractions and triggerconditions

triggeractions should point to code which should point to a string
triggerconditions should point to a code which should point to a string
(Actually, code could point to an integer representing an index in some string array)

Events shouldn't occupy a lot of memory (These are all assumptions, but they're logical ones :O)

 

[Troll-Brain]

That still doesn't change my thought, but take as it is, a simple opinion, not a fact.

 

[Magtheridon96]

Well, I still realize the importance of destroying the trigger and re-registering the events.
If events point to a trigger stack (They don't check if the same trigger is registered twice or more before adding it to the stack), then with a lot of events, this stack is going to be very large, and thus, if an event fires, it's going to loop through a very large number of triggers and evaluate/execute them (if any triggeractions or triggerconditions are enqueued)

Triggers aren't even touched by the event if there are no triggeractions or triggerconditions (I know because I registered 30000 events to the same trigger, fired the event and no lag spike or tiny FPS drop occured (not even 1 FPS)

 

[Troll-Brain]

This is just pure guess, no facts at all.

Triggers aren't even touched by the event if there are no triggeractions or triggerconditions (I know because I registered 30000 events to the same trigger, fired the event and no lag spike or tiny FPS drop occured (not even 1 FPS)

I think it's just because you don't open a new thread (no condition/action), but create an empty trigger with an event, fire the event, then check GetTriggerEvalCount.
I expect that it still increases when a registred event fire.

 

[Cokemonkey11]

fyi, conditions don't open new threads. That's why you're supposed to use if blocks in conditions instead of actions if you can.

 

[Troll-Brain]

fyi, conditions don't open new threads. That's why you're supposed to use if blocks in conditions instead of actions if you can.

No, it's an urban legend, conditions open a new thread (or let's say the op limit is reset), but they are still faster than trigger actions (don't remember in which scale)

 

[Cokemonkey11]

I'd like to see your source.

 

[Troll-Brain]

It's me, you can test it by yourself with bigs loops + debug message after the loop (close to op limit) in several trigger conditions, and then evaluate or fire the trigger event, all messages will be displayed.

Btw, each time code or boolexpr is involved in a native "function", the op limit is reset.
Like ForForce, GroupEnum...

 

[Cokemonkey11]

I didn't test it with op limits, I tested it by crashing the thread in a boolexpr.

Quick example which will crash the thread -

scope crashThread initializer i
	private function c takes nothing returns boolean
		call TriggerSleepAction(0.)
		call DisplayTextToPlayer(GetLocalPlayer(),0,0,"This won't display because TSA crashed the thread!")
		return false
	endfunction
	
	private function i takes nothing returns nothing
		local trigger t=CreateTrigger()
		call TriggerRegisterTimerEvent(t,1.,false)
		call TriggerAddCondition(t,Condition(function c))
		set t=null
	endfunction
endscope

 

[Troll-Brain]

TriggerSleepAction really, nothing is shocking you ?!

I'm not saying shit, it really resets the limit op.

 

[Cokemonkey11]

I'm not really following why that matters. If you use ExecuteFunc() in that boolexpr you can easily display the text after a TSA.

 

[Troll-Brain]

I'm just saying that trigger conditions resets the limit op.

I shoudn't have said that it opens a new thread.

Now, you are unable to use sync natives, TSA (this one seems obvious, it is not called TriggerSleepCondition), PauseGame and probably some other functions inside them.

EDIT : Nothing is multi-threaded in wc3, when a new thread fire, the previous one is halt, but we still can say than triggerconditions open a new thread.
I got confused by your answers, but if you say that triggerconditions don't open a new thread, then we can say the same for all other jass operations.

library ConditionsTest initializer init

    globals
        private constant integer ITERATIONS = 23000 // limit op reached with 24000 ( "ok" not displayed )
    endglobals

    private function Cond0 takes nothing returns boolean
        call BJDebugMsg("the thread will crash")
        loop
        exitwhen false
        endloop
        call BJDebugMsg("this message will never be displayed")
        return false
    endfunction
    
    private function Cond1 takes nothing returns boolean
        local integer i = 0
        call BJDebugMsg("1")
        loop
        exitwhen i == ITERATIONS
        set i = i+1
        endloop
        call BJDebugMsg("end 1")
        return false
    endfunction
    
    private function Cond2 takes nothing returns boolean
        local integer i = 0
        call BJDebugMsg("2")
        loop
        exitwhen i == ITERATIONS
        set i = i+1
        endloop
        call BJDebugMsg("end 2")
        return false
    endfunction

    private function init takes nothing returns nothing
        local integer i = 0
        local trigger trig = CreateTrigger()
        call TriggerAddCondition(trig,function Cond0)
        call TriggerAddCondition(trig,function Cond1)
        call TriggerAddCondition(trig,function Cond2)
        call TriggerSleepAction(0) 
        loop
        exitwhen i == ITERATIONS
        set i = i+1
        endloop
        call BJDebugMsg("ok")
        call TriggerEvaluate(trig)
    endfunction
    
endlibrary

I also confirm this :

Btw, each time code or boolexpr is involved in a native "function", the op limit is reset.
Like ForForce, GroupEnum...