[Clarifying] Using Excessive Events

Please think in terms of GUI, I'm not quite ready to evolve over to JASS.

Okay, so I'm making this trigger, it's so that I can do extremely flexible triggers with ease.

Does having too many events lag?

Here are tasks I am or trying to do:

Would it lag if that hit... say 5000 events?

And another task... what if I used that same thing to refer to a JASS trigger?

And another thing... would it be quicker to do entire spell triggers inside that one trigger, or would it be more logical to have a series of other triggers to be able to be used for reference. In other words, I would have all the triggered spells in 50 other things, then I would use the trigger that's building up events from the above method to refer to those triggers by running them.
So would using a trigger to refer to other triggers be faster than having a 100000000000 line long trigger just all over one system?

Well, events will take space. But as far as I know, they do not lag like any other type of traditional leak. I would say that you're probably fine as far as that goes.
If you used JASS, I suppose you could destroy the trigger and re-create it every once and a while, which would clear the space used by the events....

A 100000000000 line long trigger will probably hit the opcode limit, so I wouldn't try it. Just a joke...

As far as an enemy unit takes damage trigger, it won't lag unless the amount of units taking damage each second is relatively high AND the trigger itself that is run is not optimized. If say you were making a tower defense map (notorious for lots of units): the trigger was firing 400 times per second and you have some very slow function calls inside such as 10 gamecache calls then and only then will it begin to lag.

Make sure your GT Rawr Imma Eatchu trigger is very optimized and you'll be OK. If you want to code alot of spells inside of it, it should be fine as long as it is an if ... elseif ... elseif ... elseif ... elseif ... ... .. endif OR some sort of array lookup.

I'll tell you now, you are going to want to stay away from gamecache, and make only 1 call if absolutely necessary.

To test it create 5+ units with a lot of hit points and hp regen (no attack, can't flee) surrounded by at least 200 long range fast attacking invulnerable units with splash damage. Increase the numbers as you see fit. If it doesn't drop your FPS you're good to go.

In most of my experiences, FPS drops were due to spikes of code being executed. Unit Takes Damage events usually fire evenly over time, whereas timers with long loops which fire every 0.5 seconds tend to lag alot more.

maby add another trigger that removed the event when a unit dies to help manage the size of the event list.

Is that more efficient than having a trigger with 50 bajillion actions/lines in it?

No because it has to check for 6 if's as opposed to the one event that it would have the other way

So if I use those tacky 'If, Then Else - Multiple...' things, it will do the same thing but more efficiently?

No. The CPU cost is: number of event fires * CPU usage at each fire.

The number of event firings is pretty well fixed - all you can do is minimise the CPU usage at each one.

Though the second one has better memory usage, it is less efficient CPU wise.

I... didn't fully comprehend that post...

what he is saying is that the second method you have will use less RAM however more CPU as for the first method it will use more RAM but less CPU, and as far as my experience goes RAM is is a much more plentiful supply then CPU.

EDIT: The reason for that is each if..then statement uses CPU. The more CPU you use per fire (event) the more the load will be on the CPU because lets say one if then else uses 1% CPU and you have 5 if then statements that would use 5% of your CPU and lets say that it is fired 60 times a minute. That would mean that 5% of your CPU is used once every second by that one statement. Now lets say we have the same 60 times a minute but we dont have it with 5 if then statements, instade we use the large event list. That would mean that our CPU usage would be a lot less due to eliminating the use of the CPU in regards to the if then statements. However a large event list would take more space in RAM because it would need more events that it fires off of, instade of that, the one event is trimmed down into a specific thing however that trimming takes CPU usage.

Basically it is like this:

Option A: (large event list)
fires off specific unit
uses more RAM due to the large event list

Option B: (if then method)
fires off ALL units
uses more CPU due to an increase in the rate that the trigger executes
uses more CPU due to the computation effort from an if..then statment

PS: Sorry but im tired so if I dont make sence tell me

PPS: the 5% is an extreme and in reality it is much less that was just used as an example

So if I make a billion triggers and then refer to them, it will use CPU > RAM BUT if I make one trigger with a shit load of actions, it will use RAM > CPU?

not necesserly read my edit above.

ne ways tho having a billion triggers would take RAM (think of it the more writing you and the computer does the more RAM)

And the long list of actions would use more CPU due to that the CPU has to do more work to decide what action it really should do, basically it has to think 1+1=2 instade of just knowing that 1+1=2

Ah, so making one mother-fucking huge trigger would be more efficient than gazillions of interlocked (via 'If/Then/Else') triggers?

yes it would be more efficient on the CPU... now there does need to be some tradeoff sometimes lets say one if then would remove the need fore 1000000 events, id go with the if then, because even tho it would use a little more CPU doing it the other way would use a LOT more RAM

So for small things (e.g a chain hex) I would add those to the main trigger, whereas huge things (e.g chain hex feedback cluster star fall arrows) I would If/Then/Else it to another trigger?

Things like that, would that be efficient to use both methods?