I read in a post on here a couple of days ago that setting any function call like (last created unit) to a variable for use throughout the rest of the actions is "easier" on the calculations the trigger has to make. This might have been a recent post, but I feel like it was in a dead post that came up in a forum search.
For example, You have an action to make a marine and order him to attack move to a couple of points before returning to his spawn point and being removed. (A simulated patrol)
According to the poster, instead of using (last created unit) for the next 4-5 actions, make an action directly after the creation to set variable(patrolling marine)=(last created unit) and call the variable for any actions that call for it. I'm just wondering if this has any validation from a technical standpoint. I find myself using a lot of local variables simply because it's "easier on the eyes" and my mind can make sense of the script faster when the name of the variable makes more sense than the actual function series.
Do local and or global variables generate any processing lag as "dead" information, or do they improve performance by temporarily storing information so the computer doesn't have to check the same thing every time?
And could this be taken one step further by making a global record for variables that you only use in one trigger? Or should those stay as local variables so that they can be forgotten each time the trigger ends?
Are we talking global or local variable referencing, if you are just using the unit in that trigger only it's easier to use last created unit (unless you create a whole bunch of units obviously). If you need to reference the unit in another trigger, you want to use a global variable since while last created unit can work, but it can also change at any given time, based on creation of a unit.
One could argue that while they decrease the RAM eaten by running the function multiple time, they also increase the overhead memory requirements.
If you make a record, you can use local record variable to utilize it in each trigger. Remember that variables aren't erased from the memory when exiting a trigger just simply wiped clean, since the trigger still exists in memory (so that events can run it).
He was speaking specifically of local variables. Basically, the logic of his argument was if there were more than 10-12 functions referring to a unit, even if it wasn't the same unit each time, to make a local unit variable and then change it as needed. Change it to unit 1, use it 3 times, change it to unit 2, use it 3 times, change it to unit 3, use it 3 times, and then let it be wiped clean when the trigger ended.
It made sense, and since I was already doing it anyway, it just kind of slipped my mind. But I was looking at a local variable list of mine that had over a dozen variables, and I was just wondering what makes a map or mod more efficient.
Because I'm still figuring out a lot of the Data side, most of the functionality of my map comes from triggers. My map isn't performance intense so it doesn't matter, but in a 8 player FFA, would it be better for most things to be done in the data window as opposed to my frequent trigger "workarounds".
i personally use the "last variables" (last created unit, last created, w/e) only once by assigning a variable to it. you also "loose" reference over time. in your example if you remove last created unit when the marine arrives (if he arrvies) it would remove a totally different unit.
Variable access in general is faster than function calls, because each function call introduces some additional overhead. The overhead typically increases with the amount of parameters, because each of them needs to be copied to the functions local stack.
However, in practice, these differences rarely matter. As a beginner, make sure to focus on correctness instead of performance.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I read in a post on here a couple of days ago that setting any function call like (last created unit) to a variable for use throughout the rest of the actions is "easier" on the calculations the trigger has to make. This might have been a recent post, but I feel like it was in a dead post that came up in a forum search.
For example, You have an action to make a marine and order him to attack move to a couple of points before returning to his spawn point and being removed. (A simulated patrol)
According to the poster, instead of using (last created unit) for the next 4-5 actions, make an action directly after the creation to set variable(patrolling marine)=(last created unit) and call the variable for any actions that call for it. I'm just wondering if this has any validation from a technical standpoint. I find myself using a lot of local variables simply because it's "easier on the eyes" and my mind can make sense of the script faster when the name of the variable makes more sense than the actual function series.
Do local and or global variables generate any processing lag as "dead" information, or do they improve performance by temporarily storing information so the computer doesn't have to check the same thing every time?
And could this be taken one step further by making a global record for variables that you only use in one trigger? Or should those stay as local variables so that they can be forgotten each time the trigger ends?
Are we talking global or local variable referencing, if you are just using the unit in that trigger only it's easier to use last created unit (unless you create a whole bunch of units obviously). If you need to reference the unit in another trigger, you want to use a global variable since while last created unit can work, but it can also change at any given time, based on creation of a unit.
One could argue that while they decrease the RAM eaten by running the function multiple time, they also increase the overhead memory requirements.
If you make a record, you can use local record variable to utilize it in each trigger. Remember that variables aren't erased from the memory when exiting a trigger just simply wiped clean, since the trigger still exists in memory (so that events can run it).
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
@willuwontu: Go
He was speaking specifically of local variables. Basically, the logic of his argument was if there were more than 10-12 functions referring to a unit, even if it wasn't the same unit each time, to make a local unit variable and then change it as needed. Change it to unit 1, use it 3 times, change it to unit 2, use it 3 times, change it to unit 3, use it 3 times, and then let it be wiped clean when the trigger ended.
It made sense, and since I was already doing it anyway, it just kind of slipped my mind. But I was looking at a local variable list of mine that had over a dozen variables, and I was just wondering what makes a map or mod more efficient.
Because I'm still figuring out a lot of the Data side, most of the functionality of my map comes from triggers. My map isn't performance intense so it doesn't matter, but in a 8 player FFA, would it be better for most things to be done in the data window as opposed to my frequent trigger "workarounds".
i personally use the "last variables" (last created unit, last created, w/e) only once by assigning a variable to it. you also "loose" reference over time. in your example if you remove last created unit when the marine arrives (if he arrvies) it would remove a totally different unit.
@FunkyUserName: Go
If I ever have a trigger that runs long enough for the unit it created to be removed by the same trigger, something is wrong. lol.
I definitely know what you mean. Anytime you want to play an animation or sound on a unit 3 units ago, you're screwed without those variables.
Variable access in general is faster than function calls, because each function call introduces some additional overhead. The overhead typically increases with the amount of parameters, because each of them needs to be copied to the functions local stack.
However, in practice, these differences rarely matter. As a beginner, make sure to focus on correctness instead of performance.