| 04-12-2006, 10:26 PM | #1 |
I thought of a method for the "tempPoint" variable (used to prevent leaks) of using array values for specific triggers; ie: tempPoint[1] is used in Trigger 1, tempPoint[30923952] used in Trigger ...yeah. This is so that the values don't get tangled when used at the same time; ie: Trigger 2 fires every .50 seconds, and uses tempPoint twice. At the same time, a trigger is fired when a spell was cast, and it also uses tempPoint. There might be a collision with the value of tempPoint if they are fired at the same time, but that seems pretty unlikely. All of this, however, is theoretical but it does make sense (to me at least). My question is whether it really is necessary to assign individual "ID"'s to a trigger so that it doesn't collide with other values, and whether doing this hogs up a little more memory/processing power than not doing it. (do variables with array values require more power to run than non-array variables?) |
| 04-12-2006, 10:47 PM | #2 | |
Quote:
this is useless if you dont null and destroy, the leaks are still there, you are just not overlapping them |
| 04-12-2006, 10:48 PM | #3 |
Two triggers can not run at the same time. Only one trigger may run at once, and does so until it finishes, reaches a wait action, or it runs another trigger (through the run trigger action or by causing it's event to fire with one of it's actions), at which point the currently running trigger is put on hold and the next one runs. |
| 04-13-2006, 04:40 AM | #5 | |
Quote:
Oh okay, I was never 100% sure how triggers were actually ordered to fire. Thank you for clearing that up. |
| 04-13-2006, 04:45 AM | #6 | |
Quote:
So you can easily use another variable such as tempPoint2[#] (for example) for triggers that need two temporary points? This method seems much easier than having to assign an ID to each trigger. Thanks a lot. |
| 04-13-2006, 07:58 AM | #7 |
Variable arrays take far, far more memory than ordinary variables. There is no need to have a variable array for temp variables, as they are not needed for any length of time (if they are, eg: there is a wait, I'd suggest using a trigger specific variable called something else). |
| 04-13-2006, 08:38 AM | #8 |
well, maybe it's not a leak, but it still takes up memory, so wat is the point? Especially when u wanna run periodic event, u maybe able to keep the handles, but they will eat memory like hell |
| 04-13-2006, 09:24 PM | #9 |
A variable array does take more memory than an ordinary variable. However, this memory is bounded and very small-about 32kB. In comparison, every single handle object consumes at least on the order of a kB (700B? I measured once, but forgot. Will check again.) In any case, this does more than let the user take care of memory leaks, as it allows a GUI user to use variables for anything, with little hassle, as everything can be done from the drop down menus, with out having to worry about whether things will work through any myriad of multithreading issues-waits are not the only potential trouble source. MaD[Lion], please elaborate on your concerns with a concrete example. A far better long term solution to pappi.chullo's problem is writing JASS directly, however, for now he can use this as a band aid. |
| 04-13-2006, 09:28 PM | #10 |
Yea, but purely for temp variables, there isn't any risk of them interferring with each other, and when there IS a risk, it is better just to make a new variable, as that takes up less memory. One variable array = ~46 handle objects? That backs up my point - effectively 46 less handles for one variable array less. |
| 04-13-2006, 09:44 PM | #11 | |
Quote:
Anyway, you CAN'T just make a new variable so easily. What if you have a trigger that runs more than once instance of itself simultaneously? How are you going to tell one version to use variable A, and the other to use variable B? Even different triggers-how are you going to keep track of which uses what? 46 handles is nothing, nor is it comparable, as handles take up somewhat special memory-memory that warcraft must keep an eye on for desyncs. I am glad that you point out room for "by-hand" optimization, and I will reiterate that the best long term solution is to learn JASS and use warcraft's local variable syntax. Fundamentally though, this is O(1) in memory used and time spent-what more could you ask for? |
| 04-13-2006, 09:48 PM | #12 |
Well, if there is a risk, then it is obviously no longer what I consider a temp variable. But yea, JASS would be better. I can't be bothered though, and I never have trouble with variables overlapping (locals would come in handy for MUI though...). Meh, it's not that big a problem. |
