Add more built-in procs to the cpu profiler

ID:1501984
 
Feb 20 2014, 9:13 am
Applies to:Dream Seeker
Status: Open
Issue hasn't been assigned a status value.
Hey would it be possible to add a few more built-in byond procs to show in the cpu profiler?

Such as view(), range(), get_dist(), step(). Mostly the ones that would be "the laggiest" if overused.

Ok thanks
Feb 20 2014, 11:00 am
+1

Good luck.
Feb 20 2014, 2:30 pm (Edited on Feb 20 2014, 2:52 pm)
+1
Edit: The reason why I'm giving a +1 is because the profiler only seem to help me only so much in optimizing my projects. In the end, I have to check through my code myself, trying to think of ways to shorten things that may or may not be possible to be shortened.
Feb 20 2014, 2:39 pm
+2,000
Feb 20 2014, 11:20 pm
+1
Feb 20 2014, 11:28 pm
I think the problem with this is that those procs aren't actually attached to anything, so you'd have trouble pinpointing what view() call for instance was bogging things down because the profiler would have no way of determining what that view() call was attached to.

And since you'd basically be calling the same proc for every instance of a proc called without a reference (these procs exist even outside of the /global scope) you'd just have a ton of numbers spanning tons of instances of calling that proc in your code.

It would be awesome if it were possible though, agreed, and I could very-well be wrong about what information the profiler could potentially obtain from the calls but just thinking about how those procs work makes it seem like it might be a bit unfeasible.
Feb 21 2014, 9:53 am
You can get profile numbers for other void procs. Also the numbers would be solely for the proc itself. If you want info on a proc calling another proc, that's what total cpu is for.
Feb 22 2014, 10:27 am
I'm pretty sure that my over use of view() in my game is a big source of "lag"

I would like to see the exact numbers in the profiler though before I bother trying to optimize it.

I could replace most of my uses of view() with something like this which is far more conservative:
proc/Area_view(range=20,atom/center)
    var/area/a=locate(/area) in range(0,center)
    var/list/players=new
    for(var/mob/m in a.player_list)
        if(get_dist(center,m)<=range)
            players+=m
    return players

It doesn't take turf opacity into account, but for most purposes I'm willing to make that sacrifice. Such as with chatting.
Feb 22 2014, 1:54 pm
Ter13 looked into a comparison between view/range and viewers/hearers that you might find interesting. You can find it here.
Feb 22 2014, 2:53 pm
Cool thanks I always wondered how they compare