Loops

ID:2310212
 
Oct 29 2017, 9:56 pm
(See the best response by FKI.)
In my code I track key presses for player movement through a global Loop proc, which runs the movement proc for all active players once per tick.
Currently the proc is activated on all players by using a for loop containing them. Which would be more efficient, having the global proc run the movement proc once per tick on players through a for loop, or give each player their own movement loop proc that runs independently?

Basically, this?
proc
    WorldProc()
        var/ticks=0
        while(1)
            for(var/mob/M in players)
                M.StateMachine()
                M.LocationUpdate()
                M.oppositedir=M.BehindDir()
                M.Movement()
                if(M.escape)
                    M.escape-=1
                    if(M.escape<=0)
                        Flash(M,rgb(255,255,255))
                        M.escape=0
                if(!(ticks % 5))
                    M.StaminaDrain()
            ticks++
            sleep(0.1)

or this?
mob
    proc
        MovementLoop()
            set waitfor=0
            while(src)
                StateMachine()
                LocationUpdate()
                oppositedir=BehindDir()
                Movement()
                if(escape)
                    escape-=1
                    if(escape<=0)
                        Flash(src,rgb(255,255,255))
                        escape=0
                if(!(ticks % 5))
                    StaminaDrain()
                ticks++
                sleep(0.1)

Oct 31 2017, 1:10 pm
Best response
I had a longer response, but net...

In short, I would not use the first loop as it has no ability to scale. I would recommend changing the second loop to run on demand, and also implement this (http://www.byond.com/forum/?post=2055964&first_unread=1). Cannot go wrong.
Oct 31 2017, 2:12 pm
In response to FKI
Mar 20 2016, 10:08 am

I haven't seen one of these in awhile, so I guess he's either MrSoberOne now or he just got better sleeping patterns.
Nov 3 2017, 12:11 am
In response to FKI
Thanks for your help. Could you explain what "ability to scale" is to me?
Nov 3 2017, 4:48 am
In response to DimensionalRift
In other words, that loop (snippet #1) will run with no issues with a minor amount of players, but gets progressively worse as player count increases. You will not run into that issue using the second method.

@Unwanted4Murder: Lol'd.
Nov 3 2017, 5:41 am
In other words, that loop (snippet #1) will run with no issues with a minor amount of players, but gets progressively worse as player count increases. You will not run into that issue using the second method.

That's pretty inaccurate, but you came to the right conclusion anyway.


#1 will be slower than #2 because:

- It's creating a copy of the list of players to operate over.

- It's looking up M every time you want to access a variable.


#2 will be slower than #1 because:

- More of these running means more scheduler insertions. As a general rule, the more things you have actively sleeping, the worse the performance of scheduler insertions gets.


Realistically, #2 is a better pattern than #1, but #1's ideology isn't actually wrong.

Even so, the number of players in the world will probably be a non-issue for this specific sample. I'd lean #2 because you aren't likely to reach over 200 players. Scheduler insertion times only start to really matter when you get into the tens of thousands.
Nov 3 2017, 6:22 am
In response to Ter13
Realistically, #2 is a better pattern than #1, but #1's ideology isn't actually wrong.

Sums up what I meant to convey.

Up-voted, as this is the better answer.