Will this Lag?

05-13-2006, 09:02 AM

I have eight players, and each player has a backpack that needs to follow him around. What I need to know is; will a loop running this often lag up the game, aside from memory leaks and such? And if it will, is there a more efficient way of doing it?

Trigger:

Backpack Update

Events

Time - Every 0.30 seconds of game time

Conditions

Actions

For each (Integer A) from 1 to 8, do (Actions)

Loop - Actions

Set Backpack_TempPoint = (Position of Player_Heroes[(Integer A)])

Custom script: call SetUnitX( udg_Player_Backpacks[GetForLoopIndexA()], GetLocationX(udg_Backpack_TempPoint) )

Custom script: call SetUnitY( udg_Player_Backpacks[GetForLoopIndexA()], GetLocationY(udg_Backpack_TempPoint) )

Custom script: call RemoveLocation ( udg_Backpack_TempPoint )

05-13-2006, 09:20 AM	#2
Captain Griffen	Do you really need 0.3 second interval? Also, GetForLoopIntegerA() is a function, is that needed (probably faster to use a variable directly)?

05-13-2006, 09:24 AM

blu_da_noob

Trigger:

Backpack Update

Events

Time - Every 0.30 seconds of game time

Conditions

Actions

For each (Integer A) from 1 to 8, do (Actions)

Loop - Actions

Custom script: call SetUnitX( udg_Player_Backpacks[GetForLoopIndexA()], GetUnitX(Player_Heroes[GetForLoopIndexA()]) )

Custom script: call SetUnitY( udg_Player_Backpacks[GetForLoopIndexA()], GetUnitY(Player_Heroes[GetForLoopIndexA()]) )

That would be better. Also, such a trigger shouldn't lag on it's own, but could potentially contribute to lag in the map.

05-13-2006, 09:25 AM

iNfraNe

No it wont lag.
This is quicker and better tho:

Trigger:

Backpack Update

Events

Time - Every 0.30 seconds of game time

Conditions

Actions

For each (Integer A) from 1 to 8, do (Actions)

Loop - Actions

Custom script: call SetUnitX( udg_Player_Backpacks[bj_forLoopAIndex], GetUnitX(udg_Player_Heroes[bj_forLoopAIndex]) )

Custom script: call SetUnitY( udg_Player_Backpacks[bj_forLoopAIndex], GetUnitY(udg_Player_Heroes[bj_forLoopAIndex]) )

which removes the location creation since you dont really use it as a location anyways, this is alot faster, and you could even run it every 0.01 secs (if you dont have any other laghungry triggers).

Edit: blu is fast.
Edit: and wrong, he forgot udg_ in front of the hero variable :p

05-13-2006, 10:32 AM	#5
Rao Dao Zao	Hmmz, thanks lads, that puts my mind at rest. Just wondering, because I'd heard that constantly running triggers can cause problems.

05-13-2006, 10:55 AM	#6
iNfraNe	Thats only if you dont fix up memory leaks. Periodic trigger themselves do not lag.

05-13-2006, 11:00 AM	#7
Captain Griffen	They take up a small (temporary) amount of memory, and a small amount of processing power though, so can add to lag.

05-13-2006, 11:06 AM	#8
iNfraNe	That can be ignored, only their contents are of concern. If I make 1000 triggers that run periodic each 0.01 second without content it will not lag.

05-13-2006, 04:20 PM

Vexorian

Trigger:

Backpack Update

Events

Time - Every 0.30 seconds of game time

Conditions

Actions

Custom Script: local unit u

Custom Script: local unit a

For each (Integer A) from 1 to 8, do (Actions)

Loop - Actions

Custom Script: set a=udg_Player_Backpacks[bj_forLoopAIndex]

Custom Script: set u=udg_Player_Heroes[bj_forLoopAIndex]

Custom script: call SetUnitX(a, GetUnitX(u) )

Custom script: call SetUnitY(a, GetUnitY(u) )

Custom Script: set u=null

Custom Script: set a=null

Check out, access to bj_forLoopAindex then udg_Player_Backpacks and finally evaluating the position of the array besides of the lengthy names, doing stuff twice is something I would never recommend

Also GUI's for each integer A ... thing is slow besides you can get rid of the darn trigger and save much more

JASS:

function BackPack_Update takes nothing returns nothing
 local unit u
 local unit a
 local integer i=1
       loop
       exitwhen i>8
             set a=udg_Player_Backpacks[i]
             set u=udg_Player_Heroes[i]
             call SetUnitX(a,GetUnitX(u))
             call SetUnitY(a,GetUnitY(u))
             set i=i+1
       endloop
 set u=null
 set a=null
endfunction


function InitTrig_Backpack_Update takes nothing returns nothing
 call TimerStart(CreateTimer(),0.3,true,function BackPack_Update)
endfunction

And to answer the question, not even the first trigger is supposed to cause any noticeable lag. 0.3 seconds is kind of a huge delay

edit: I have my doubts if accessing the array twice is really slower than using aux variables that then need to be set to null

05-13-2006, 06:00 PM	#10
iNfraNe	Well, why dont you test it then? :) I think the array way is faster.

05-13-2006, 06:55 PM	#11
Vexorian	I don't have the time, and by the use of logic and mostly because of the over sized variable names I am almost sure that it would be slower

05-13-2006, 08:07 PM

#12

iNfraNe

Hmm I tested it like this:

JASS:

function test takes nothing returns nothing
  local integer i = 0
  local unit u
    loop
      exitwhen i > 100
      set u = udg_Player_Hero[1]
      call SetUnitX(u, GetUnitX(u))
      set i = i + 1
    endloop
  set u = null
endfunction

Ran that like.. 10000 times, and it took 13.2 seconds
Then I ran

JASS:

function test takes nothing returns nothing
  local integer i = 0
    loop
      exitwhen i > 100
      call SetUnitX(udg_Player_Hero[1], GetUnitX(udg_Player_Hero[1]))
      set i = i + 1
    endloop
endfunction

Which took 12.3 seconds... I'd say there's no real difference.. since barely 1 second over millions of times called, who cares.

05-13-2006, 08:13 PM	#13
Vexorian	err, you didn't understand what I said at all. Try with a longer name for i . like local integer ii_iiiiiiiiiiiiii

05-13-2006, 08:22 PM	#14
iNfraNe	That would be even slower then yes. Wasnt this about testing if the longer names/array made up for the setting of the local and the nulling?

05-13-2006, 08:48 PM	#15
Vexorian	the total size including the variable used by the index, in the above case it was bj_forLoopAIndex which is quite long. Also in this case there are 2 different arrays used and the set to null should be inside the loop