Simple Question about Multiple periodic triggers

[GoldenBud]

Hey all, so my question is simple. My map is a maze/dodge/slide and I use ALOT of Loops, in quite a few different periodic triggers that are running .03-.1 sec simultaneously. Most of them have quite a bit of code and almost always consist of loops with ITE's that contain more than one condition. It was recently brought to my attention that conditions are pretty demanding, but enough ramble.

Anyways, my question is: Is it better to compile as many functions and loops as i can into a single periodic trigger, or, is it better to have them split up into their own triggers?

For example I have 3 different slide loops/ITE'd all nested in the same .03 periodic. Would it have more or less impact on performance if i seperated them? Would it matter at all?

I need to limit my demand as much as possible.

 

[TriggerHappy]

I would say it's slightly more efficient to have them in the same periodic trigger. Although if you really want optimizations on high frequency code you may want to switch to JASS.

If you post your triggers maybe you can get some optimization tips.

 

[Pyrogasm]

In my opinion, the code inefficiency that GUI adds vastly outweighs the differences in execution time if you were to put them all in the smallest number of periodic timers/triggers possible. You'd be much better served optimizing your code by replacing function calls with values stored in variables, streamlining your ifs, and/or converting some of your GUI trigger systems to JASS functions.

 

[IcemanBo]

I would have them seperated (for me more readable) and turn them off if they have heavy actions like "Pick All Units On Map And Do Actions".

 

[Dr Super Good]

I would suggest focusing on optimizing your code complexity. Chances are there are a few O(n) complexity operations than can be changed to O(log(n)) or O(1) for large performance gains.

Single trigger is most efficient if all tests must be performed all the time. Separate triggers can be more efficient if some of them can be turned off some of the time.

Before focusing on optimizing performance I suggest focusing on removing all leaks. It is completely possible your code has leaks you are not even aware of as a result of the local declared local handle variable reference counter leak on return bug. Many GUI group functions suffer from this leak.

 

[Pyrogasm]

local declared local handle variable reference counter leak on return bug

//?

function foo takes handle other returns nothing
    local handle h = SomeHandle()
    call bar(h, other)
    //don't do:
    //set h = null
    //h doesn't decrement counter, other is fine?
endfunction

 

[IcemanBo]

@Dr Super Good
@GoldenBud should not care for rewriting GUI functions to keep ensured some funcs null variables. I find this isn't a very good suggestion. GUI users have to face others problems, like some structure in code.

However, even if it would be more perfomant to have 1 trigger doesn't mean it's better. One should only combine logics ina trigger which has major aspects in common, and not arbitary combine any random code to gain 2 miliseconds.

@Pyrogasm
yes, but the problem with return is if you want to return a value, so you can not really null it anymore:

function foo takes nothing returns unit
    local unit u = CreateUnit( ... )
    return u
    set u = null // won't happen
endfunction

It also is a agent problem, not for all handles, btw! (Memory Leaks)

 

[Dr Super Good]

should not care for rewriting GUI functions to keep ensured some funcs null variables. I find this isn't a very good suggestion. GUI users have to face others problems, like some structure in code.

They have to face this problem as well... Leaking handle indices is bad as that can also cause game stability problems after a while. Especially for triggers that run with a high frequency like his.

function foo takes handle other returns nothing
local handle h = SomeHandle()
call bar(h, other)
//don't do:
//set h = null
//h doesn't decrement counter, other is fine?
endfunction

The top will cause the handle h to never be recycled at a later time, even if the object h represents is removed/destroyed. With the bottom assignment uncommented it will allow the handle in h to be recycled at a later time as the reference counter to h is being correctly decremented. As IcemanBo mentioned, this only applies to some handles such as unit, location, group, force, effect, etc.

Before the function returns the value in h must be null. AS IcemanBo shows this is problematic when one is trying to return the value in h as one cannot null it directly. There are 3 work around solutions.

• Make h a function parameter that argument is ignored. Function parameter declared local variables do not suffer from the reference counter leak on return bug. This has the disadvantage of slower function calls and less logical function declarations.
• Use a temporary globe variable temp_h to hold the value of h. One can then null h and then return temp_h. Since this code is executed immediately there is no concern of the value of temp_h changing between allocation and return. Global variables do not suffer from any such reference counter leak bug. This is probably the most practical solution for such functions.
• Design your functional declarations such that you never need to return handles. This can be the most efficient but can also result in rather weird and counter intuitive design.

 

[Pyrogasm]

I know why that leaks and how to fix it, just was confused by your wording because I don't think I've ever seen it with a fully descriptive name before. Checking to make sure something about that didn't change while I was gone.

 

[GoldenBud]

Thanks so much guys, I got a tun of great answers. To be quite honest I had forggoten about this post due to the moderation period lol!

@Dr Super Good thank you for the best and most relavent answer! I have spent alot of time on the Galaxy edior and switching back to warcraft (because of how special WC3 is in comparison to SC2) was hard because of leaks! At the moment I'm leak free, at least to the best of my knowledge, and after a full playthrough of the levels currently available there is no blackscreen, no random frame drops, and everything seems smoothe still.
@TriggerHappy When the time comes for me to release a full version I will most certainly be uploading and asking for optimization tips and tricks! Jass is something I always wanted to learn but the GUI has always gotten the job done. I like the challenge of a small box, if that makes any sense, though I've recently become aware of how even jass limits you in the editor.

However, even if it would be more perfomant to have 1 trigger doesn't mean it's better. One should only combine logics ina trigger which has major aspects in common, and not arbitary combine any random code to gain 2 miliseconds.

This made me think, thank you for your response. I'm often scrolling through a big wall before I can adjust ITE's at the bottom, so more than once now I've wasted alot of time just looking for what I'm trying to adjust lol...

Again thanks everyone! +rep to all, its a blessing to stop lurking and finally ask some questions!

 

[GoldenBud]

My map is Currently only available on the ent hosting service, Golden Shift 2, It's still very early but for any of you that may enjoy a Maze/Slide now and then its a fun concept I haven't seen used on wc3 for over a decade. It's early, but its fun, give it a try!

Once it reaches a further level of development I'll post it here and on EW and start a new thread on my trigger optimization!

Thanks again, till next time.