one of the appearances that open space tiles add as vis_contents was an unchanging grey cover. its useless to keep it as vis_contents since its not supposed to change so its better to have it as an overlay. its possible that i can make openspace tiles not add the turf below as vis_contents and instead listen to objects entering and leaving it with connect_loc and add those objects as vis_contents then but that sounds like more trouble than its worth
edit: probably not the last part
overlays < vis_contents in maptick cost
also tramstation has the most open space tiles in high traffic areas compared to other maps. openspace tiles have 2 vis_contents each, equivalent to 2 objects that sendmaps processes every tick this pr only makes it 1 appearance in vis_contents. its also the map with the current highest maptick per player according to lemons graphs
Adds `USE_BYOND_TRACY`, which automatically loads a given
prof.dll/libprof.so using https://github.com/mafemergency/byond-tracy/.
Not intended for use in production, and we do not ship a copy of
byond-tracy. It is extremely easy to compile yourself, but if you're
someone interesting enough to play around with this then let me know and
I can just give you a build.
I'm going to be using this for init profiling.
## About The Pull Request
When runlevels change mid work, subsystems running behind have their
next_fire updated.
It's offset by a sum of random numbers, so things don't bunch up,
especially KEEPTIME SSs
The trouble is we have so many subsystems that get added at roundstart
that this offset gets LARGE, like 10 seconds on average.
So instead of randomly offsetting, why not "fill" a set of time slots?
Only 1 keeptime subsystem a tick, and 4 others. Then we just fill up
those buckets and get to it (also don't offset things that are already
processing)
I've talked to mso a bit about this. What he reccomended was sampling a
random time withing a 2 second window.
I'm not totally sure why, kinda waiting for him to tell me off, if he
does I'll fix things up.
This pattern takes the max possible delay from 16 (76 * 5 / 20)) seconds
to 0.7 (56 / 4 / 20)
It obviously scales with subsystem count, but I like this scaling a bit
better
I've applied the same pattern to the offsetting we do at the start of
Loop(), for ticker subsystems. I am less confident in this, it does take
last fire times from at worst 3.75 seconds (15 * 5 / 20) to a static
0.75 (15 / 20)
As stated I'm less sure of this, hoping to get mso'd so I can clean
things up
## Why It's Good For The Game
Makes roundstart snappier
## Changelog
🆑
code: Roundstart "starting" should be much snappier now
/🆑
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
