overhead

ID:976680
 
Sep 14 2012, 1:16 am
(See the best response by Stephen001.)
How much of a difference would these two functions produce if being called in BYOND recursively..

This one I can see producing overhead...
get_closest()
        var/mob/closest
        var/end = 0
        
        for(var/mob/M in world)
            if(M!=src)
                var/low = get_dist(src, M)
                if(!end || (low < end))
                    closest = M
                    end = low
        return closest


replaced by this:

    get_closest()
        var/index = 0
        var/dist = 0
        for(var/a = 1, a < players.len, a++)
            var/distance = (get_difference_location(players[a],players[0]))
            if(!dist || (distance < dist))
                index=a
                dist=distance
        return index

    get_difference_location(mob/a, mob/b)
        return( (a.x-b.x)+(a.y-b.y)+(a.z-b.z) )


Sep 14 2012, 2:39 am
Overhead isn't an issue. Your proc won't run because List[0] generates a runtime error; lists start at index 1. You still need to compare player[a] to another player, though.

You made a good choice leaving the sqrt() out of the distance formula; it's relatively slow. However, you may end up with negative distances; abs() should fix that.

The two procs return different things. The first returns a mob, while the second returns an index of player[]. I suppose you're aware of this where you're using it, but I doubt it would make any difference to just return the mob at player[index] like the first proc.

Does your proc return anything at distance 0? I don't think it does. Instead of initializing dist to 0, leave it undefined (null). In the iteration, instead of !dist, use isnull(dist).

Sorry for not really answering your question, though.
Sep 14 2012, 2:48 am
psuedo.

I figure looping through numbers rather than instances is worth programming around to optimize it that much more...?

I migrated this from C#, yeah BYOND won't like players[0],
that zero index is supposed to be you, the player. again just psuedo, no robust yet.

though, you're right about returning a mob value rather than the index of the closest player. it would save an extra step.
Sep 14 2012, 3:38 am
Best response
It makes no appreciable difference what you are looping through, might even be worse I suppose in terms of the de-reference.

But essentially, that fixed list of players versus mobs in the world means you have a much smaller list to iterate over in the second example. Shrinking the data size by better data-structures (like the players list) is the big efficiency win. Everything else is kind of just bit-twiddling.
Sep 14 2012, 5:36 am
awesome. me and my paranoia
Sep 14 2012, 6:15 am
If you could vote for the answer that helped you the most, that'd be great.

I tend to vote on other people's answers quite a lot, and change my vote if a newer answer comes along later that I think answers stuff better.
Sep 14 2012, 5:32 pm
whats the difference, what is a vote?
Sep 15 2012, 2:30 am
There's a button on the right of each post, that say "0 votes" or "1 vote" etc. Votes basically let other people see which answer best fit your question, and so, might fit their's.
Sep 15 2012, 6:06 am

Vote or die motherf -er.
Sep 15 2012, 6:10 am
seems like you want a vote pretty bad. 5 bucks.
Sep 15 2012, 6:11 am
In response to Suicide Shifter
Seems you wanted that answer pretty bad. 10 bucks.
Sep 15 2012, 6:15 am
okay, 7 bucks and we'll forget this ever happened...
Sep 15 2012, 7:06 am
Oh no, the vote isn't really for me, it's mostly helpful to people searching the forums for answers later. It's just one of those things you know, that helps the community as a whole to vote often on developer help answers.