ID:1743202
 
Not Feasible
Applies to:Dream Seeker
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future
Maybe you guys could add a checkbox to the .debug profile cpu profiler to display how much built in byond procs are using.

For example view(), icon_states(), get_step() and so on.

It would be nice to have some perspective on whether I am overusing them or not instead of suffering from mystery lag with no indication as to why.

Thanks
Except no. I am the original creator. 85% of the code is made by me and the other 15% from a partner of mine. Everything you just stated is a rumor that was started and now it is commonly believed to be a fact.

Also I am really big on code efficiency. All built in BYOND functions do not run at the same speed. Compare get_dir() to view(50) and see if you still believe that.

When I replaced all instances of view() in my game with my own more specific function called player_view() the performance became much better.

If the profiler showed every function I can guarantee you BYOND's functions would take the top spot in highest cpu usage and not mine.
I don't want to derail the thread but this seems like a simple and harmless request and DOES have uses to developers.

It will also give perspective as to which built in functions are the most intensive.
I don't think this is useful. You can easily test the performance of those procs yourself. Additionally, as you get familiar with Byond and experiment, you come to know how fast things are out of experience.
In response to FKI
FKI wrote:
I don't think this is useful. You can easily test the performance of those procs yourself. Additionally, as you get familiar with Byond and experiment, you come to know how fast things are out of experience.

How would you test them yourself? They don't appear in BYOND's cpu profiler. (.debug profile)

I do know roughly how fast they are. But I need specifics, more so I need to know where they rank compared to procs I have written myself.

I could make a wrapper function for every built in function for example proc/get_dist() which calls byond's getdist(), but that would be a lot of work replacing everything I already have.
In response to Lizard_Sphere_X
Make a verb and use it in a loop, then look at the profiler.
In response to FKI
FKI wrote:
Make a verb and use it in a loop, then look at the profiler.

That doesn't help me gain any perspective about where that function ranks in the overall cpu usage when used in actual gameplay in progress.

Sure I could make a test function that calls view(99) 1000 times a second and lag everyone to hell. But it isn't going to reveal any useful data to me.

I think you are all missing the point, my only hope is that Lummox doesn't. So I'll just leave this thread here and hope for the best.
In response to Lizard_Sphere_X
If you can't infer how it ranks in general from that, then I don't know what to tell you.

Carry on then.
GatewayRa wrote:
It's a Finale rip, and no... I've never stated all build in procedures run the same, I said they'll run relatively the same speeds when the same arguments are put into them.

It's not useful; you could just encapsulate the built in BYOND procedures to check how fast they are.

I made Finale

And I thought about making wrapper functions but that is unnecessarily difficult when the game engine should have a debugger that shows these things.
++
GatewayRa, there's not a single topic I've seen where you're not saying bullshit.
In response to Kidpaddle45
Kidpaddle45 wrote:
++
GatewayRa, there's not a single topic I've seen where you're not saying bullshit.

So what you're saying is, every topic you read makes you feel inferior so you've decided to emotionally lash out at him here. Big man with big words huehue.

In response to Cloud Magic
Nevermind
I'll never feel inferior to someone on the internet.
Unlike you, I do not give a rank to someone based on the way he speaks and the shit he says.

He's no big man and these are not big words. All I said is I've never seen a post where he doesn't say bullshit. It's my opinion, you won't change it.
In response to Lizard_Sphere_X
Is that why the programming is so bad?

You should be able to test this by making a verb or proc with the built-in function and use the profiler to see what that verb/proc takes, like you've already been told to do.

Anyone with experience in the language won't care about this.
There's no need for all the arguing here. It's just a feature request after all. I will say that inefficiencies in the code are pretty much mostly due to the soft code, as the hard code is about as efficient as I can get it (though I'm always on the lookout for improvements).

Ultimately it isn't possible to profile the built-in procs. They're much too different from true procs, and the overhead of even checking if profiling was turned on would be too high to justify anyway.

Typically, if you want to find out how a built-in proc performs, you just would build a test case that calls it tens of thousands of times with various conditions, and profile that. Comparing to a control case that does nothing, or does the same thing differently, can be fairly instructive. Some of our power users have done that from time to time with various constructs, and discovered ways to improve efficiency in their code.

I will say that the procs you named specifically will tend to be slower.

view() performs a number of calculations, and is most sensitive to changes in range; it's like range()--which has a small O(N^2) footprint--but with an added (mostly) O(N^2) footprint of its own because it checks line of sight and lighting. The view code used to be much worse, running in O(N^3) time, but it's gone through some optimizations--some of them fairly recent improvements meant to help the webclient. If you need to use the same view() result frequently in a calculation, as I do in the AI for SotS II, then I recommend copying the list.

icon_states() has to load an icon. It will keep the icon in memory for some time, but you're way better off avoiding the call, since in most cases you'll never need it. It's ill-advised in time-sensitive code.

get_step(), of course, calls the built-in pathfinding. That's going to vary a lot by the current conditions, and it has a known inefficiency in that it will struggle when the destination is unreachable.
Lummox JR resolved issue (Not Feasible)