| 12-26-2006, 06:36 AM | #1 |
Is there a difference in performance/speed/efficiency between using any of the following over one another if used extensively? Trigger: ![]() Conditions
Trigger: ![]() Conditions
Or, is there anything vitally performance-differing (if used in copious amounts) between these two triggers? Trigger: |
| 12-26-2006, 09:00 AM | #2 |
Not sure. GUI does everything in a wierd, inefficient way, with extra function calls for ifs, etc. If you are worried about efficiency, I'd say use JASS. |
| 12-26-2006, 10:57 AM | #3 |
For any amount of RAM above about 32 mb, you won't notice a single difference between those triggers. The only time you might want to worry is if they start shooting off about 300 times per second. I'm not sure, but I'd say for the first part use the first one, and the second part use the second trigger. |
| 12-26-2006, 11:37 AM | #4 | |
Quote:
Thats not the point, everybody likes more effecient code than less effecient code, why wouldent we? I would prefer to have something that takes 0.0034 seconds than 0.007 seconds, would you? And that wont be the only thing thats running at the time, theyre is other things to take into consideration, and its not just that game thats working at the time, everything add ups, maybe very little, but it all helps out. |
| 12-26-2006, 02:15 PM | #5 |
I know what you mean about efficiency, but we're stuck with a limit of 100 times per second and inaccurate GUI wait commands. |
| 12-26-2006, 02:46 PM | #6 |
Hey, trigger conditions don't use a new thread, trigger actions do, so having a condition inside a condition might be faster than having it inside an action, although I seriously doubt it would have any importance unless you have in a periodic event, in which case just using a timer should actually be faster than using triggers with conditions and actions |
| 12-26-2006, 04:12 PM | #7 |
Part 1. The first one is faster, as it only needs one boolean comparsion(?spelling?) 1. JASS:(GetUnitAbilityLevel(GetFilterUnit(),'buff')>0) JASS:((GetUnitAbilityLevel(GetFilterUnit(),'buff')>0)==true) Part 2. Hmm.. here it is more difficult to say... Just a guess, the 2nd one is faster as it does not need to check triggercondition before executeing the triggeraction. |
| 12-26-2006, 04:38 PM | #8 |
TriggerEvaluate is faster than TriggerExecute, in the case scenario where the condition is false, having it as triggercondition would be faster, but if it is true it would be slower cause it has to use the condition AND create a new thread. But the speed difference doesn't really matter |
| 12-26-2006, 08:12 PM | #9 |
So simply forget that. Speed diffrences are so small. Here counts readability of the code. |
| 12-27-2006, 06:12 AM | #10 |
Hmm. Thanks for the responses guys. I have just noticed something that may have fouled up what you guys have said, however. In my first trigger I said "(Matching Unit) has buff My Buff"; this should have read "((Matching Unit) has Buff My Buff) equal to true)". BertTheJasser said that the first trigger would be faster because it only needed one boolean comparison, but that is incorrect because I typed the trigger wrong. Does that mean that they are both equally fast, then? If I understand you correctly, Vex, then you're saying that Having an "And - Condition 1 and Condition 2 are true" in the "Conditions" for a trigger would be faster than using only one condition and an If/Then/Else function because it does not create a new thread? |
| 12-27-2006, 12:37 PM | #11 |
GUI converts the things to code like my part # 2, but it is actually simpler and faster to write #1. For the speed... I would guess that they are both as fats as the other, asboth use a filterfunc, only in diffrent places. (Again, just a guess..) |
