Self CPU: How much time the proc takes to run, in seconds.
Total CPU: How much time was taken by the proc and all other procs it called, in seconds.
Real time: The same as Total CPU, also in seconds, but this includes downtime introduced by spawn() and sleep(). It is when the proc ended minus when the proc started in seconds.
Code: Select all
mob/verb/test()
for(var/v = 1 to 10000)
spawn() something()
proc/something()
sleep(100)Calls: The total number of times this proc has been called since the profiler was started.
The "Average" button averages Self CPU, Total CPU, and Real Time by the number of calls.
For optimization, you are going to want to look mostly at Self CPU. Start with your highest self CPU average and work your way down the list, improving your code where you can. Once you start getting to 0.000 averages, you are going to want to start looking at non-averaged self-cpu and work on your biggest impact functions, working your way down again.
If the realtime is high, but the self CPU and total CPU are low, it doesn't really matter, because you probably have some kind of a long-running delay going on in that function. As long as the self CPU and total CPU are fairly low, you should be alright.
You need to think about how often, and when that code is running. Sure, the self CPU might be 5.147 seconds, but if the function is being called one time during startup, before the players even connect, it's not going to be as high of a priority to optimize as something that takes 0.522 seconds and is called once every 10 seconds.
In order to understand how much of the CPU time a function is using that is an infinite loop, you need to divide the Total or Self CPU (averaged) by the Realtime. So if the averaged Real Time of a function is 647.255, and the average total CPU of a function is 30.174, this may look like it's eating up a lot of CPU time, but we divide the two values: and we get approximately 4.66% of the CPU time being used by this function. That's not low, but it's not really all that high either.
Averages can be helpful for getting a more full picture of what's going on with a function, but it can also mask problems if you have weird corner cases where a function usually only takes a few milliseconds to finish, but has a very infrequent case where it takes a really long time to finish.
