if you want to make the singulo more responsive when everything is lagging try making singuloprocess a non background subsystem (which it inherits from the parent processing subsystem) so it doesnt have to compete with atmos for the leftover cpu time. theres not really much point in singulo being background anyways since once it starts moving stuff towards it and creating active turfs its already making a bunch of work for other subsystems.
if you want to make the singulo lag the server out less:
I profiled this by spawning a singularity on upper tram and giving it a supermatter shard, then turning on the inbuilt profiler and tracy. i turned both off after the singularity left the station.
byond profiler:
tracy: <i cant upload it via the forum or discord sorry>
the first thing to know is that it creates literally thousands of active turfs, and it causes a bunch of lighting updates.
secondly most of the work spent in singularity/process() is spent in digest() to eat or pull everything in range, most of that is spent in singularity_pull() (83%) and some is spent in consume() (16%) to actually destroy it
singularity_pull() is overridden dozens of times, but the biggest cost eaters are items by a fair margin, turfs are a small portion. /obj/item/singularity_pull() has a total cost of 5.335 seconds over 11205 calls and /obj/singularity_pull() is 5.204 seconds but with 3x the calls at 33523, this is because items call throw_at() and offload work into the throwing subsystem, and then call parent which moves them with step_towards() which calls Move()
so essentially /datum/component/singularity/process() spends most of its time moving objects to itself either directly or by throwing which is offloading work to the throwing subsystem
subsystems the singularity stresses:
SSsinguloprocess (17.033 seconds total) via the obvious, eating turfs and movables within range and pulling those that arent towards itself. spams movement and qdeletes
SSthrowing (3.584 seconds total) via throwing items in singularity_pull(), note that this only handles thrown items that havent already been eaten by the singularity
SSair (47.444 seconds total) via creating a fuckton of active turfs and pipenet rebuilds
SSlighting (16.763 seconds total) via spamming lighting updates by breaking atoms with opacity and breaking/moving light sources
unfortunately all of these are pretty dense, i dont see an obvious big win here.
the best way to optimize it is probably to focus on singularity_pull(), it looks like items are moved twice every time theyre pulled because throw_at() moves when called by default, and it calls parent which moves it as well. might be better to just make them move once when pulled. you might even be able to just not throw at all and rely on the singularity to move them each time theyre in range, though that might look bad.
besides that pipes take a long time in Destroy(), there might be a better way to handle pipenet rebuilds