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 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.

Make a verb and use it in a loop, then look at the profiler.

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, there's not a single topic I've seen where you're not saying bullshit.

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.

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.