[Code maintenance] Optimization roadmap

[GDNgit]

This a roadmap that contributors can use to gauge which code functions require optimizing.
Please see https://www.paradisestation.org/espresso/paradise_main.profile_viewer.html for information on processing usage.
The below section will cover how to read the profile viewer:

What statistics to generally ignore: Real time | Total CPU

Total CPU refers to the entire function string that is called, this will often be very high due to systems being interlinked. Following cases that you may want to actually look at total CPU

• Can be used to gauge which functions are calling a more expensive function.
  You have three functions that call an expensive function. Expensive function A has a self CPU cost of 30. The three functions have a total CPU cost of 0.5, 10, and 40. You can assume that the function with a total cost of 40 is causing the majority of As' calls.

• If self CPU is higher/Lower than the total cost, this means an infinite loop has occurred in that function. Byond will terminate infinite loops automatically but this can still cause undesirable behavior and will skip some CPU cycles.

Real time is the total amount of time a function has been running. This does NOT relate to the actual cost of the function, this normally just means the function slept/spawned for a bit. I have not found a real use for this that isn't covered by anything else beyond it being funny.

What statistics are important: Self CPU | Overtime | Function calls

Self CPU is the total cycles (in millions probably IDK[it's just a value and I'm gonna say cycles because I'm used to it]) that a function takes up over the course of a round. This is by far the most important statistic for optimizing. High cycles = Very upset CPU.

• Self CPU is used to bench the cost of functions so if you wanna see what functions are taking an ungodly amount of time you look at self CPU.

• if self CPU is negative/over the total CPU limit this means an infinite loop occurred in that function.

Overtime is the amount of time that a function has lasted outside of it's given tick. Functions with high overtime are the most important functions to optimize as they cause lagspikes and just TD generally.

• Overtime often happens when a function is just doing work that is far too fucking expensive for what it should be. See View() spam for an example of common overtime contributor.

• Overtime can also happen because sleeping/early processed functions are shoving other functions later in the tick. More rare but this often happens with poorly implemented code.

Function calls are what they sound like. Tracks how many times a function is called in the round. if a function is called too much it will cause performance issues. If a function is called a LOT it may be better as a function define

• You can use function calls to correlate which problem functions are being called too much by another function similar to using total CPU.

This below section will list things that need optimizing. Difficulty will be listed by it

• Atmos calculations. Difficulty: 4.5/5
  Largely just a lot of turf check removals along with general code improvement. Many atmos functions will run a lot of calculations before actually considering if they need said calculations, such as in /datum/gas_mixture/proc/share, /turf/simulated/process_cell is just a fucking mess in it's own right, and pipelines need a refactor for just how absolutely horrible they are performance wise (Remakes lists when it doesn't need to, calculation redos, the works). Lots of work, but not exceedingly difficult work.

• Lighting calculations. Difficulty: 5/5
  Lighting often runs a lot of calculations it doesn't need too, looping through every light in the world even if they don't need to be updated is quite inefficient. This one is going to be very hard, but as lighting is ALWAYS ran it will also be very rewarding. lighting's fire is a super easy optimization though, it should call swaps and use a static list instead of remaking it.

• Hear/View spam. Difficulty: 2/5
  There's a few functions that call hear/view that don't really need to. The most horrid of them being get_mobs_in_radio_ranges which calls hear on average 400 damn times by just sending a single radio message. Silly lagspike is silly and these should be easy to remove. For radios have them use proximity components and not use 500 view calls. I won't list all cases of this individually due to how common they are.

Be like playsound, use the global mob list and just use get_dist if you can.

• Hear_say. Difficulty: 1/5
  Just a non-optimized function.

• Blend spam/GetFlatIcon. Difficulty: 4/5
  GetFlatIcon should at the least checktick instead of always running, but it's one hell of a costly function. Downstreams had a solution to use the client of the usr so that might work? Lots of things will need to be cleaned up with this one.

• TGUI updates. Difficulty: 2/5
  Some TGUI menus update oddly and cause a bit of overtime. Not nearly as bad as what it was previous to V4, but we can do better. This WILL require custom debugging tools.

• RD server controller. Difficulty: 1/5
  2010 code at it's finest. Creates a few ticks of overtime when used normally. That's fucked up! Make it just do less operations/TGUI it.

• GC subsystem. Difficulty: 3.5/5
  During a recent refactor of this subsystem it was made noticeably less efficient. Revert most of those changes and clean up the code. Hard deletes also cause overtime. Most hard deletes remaining are related to antagonist hud not being removed on body deletion and bad pipe code.

• add_fingerprint. Difficulty: 1/5
  Oldcode that can be made to be faster.

• RANGE_TURFS. Difficulty: 2/5
  The fact we use locate for this is yikes.