* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded (#65589)
This pr goes through: /client/Click(), /client/Topic(), /mob/living/verb/resist(), /mob/verb/quick_equip(), /mob/verb/examinate(), and /mob/verb/mode() and makes them queue their functionality to a subsystem to execute in the next tick if the server is overloaded. To do this a new subsystem is made to handle most verbs called SSverb_manager, if the server is overloaded the verb queues itself in the subsystem and returns, then near the start of the next tick that verb is resumed with the provided callback. The verbs are called directly after SSinput, and the subsystem does not yield until its queue is completely finished.
The exception are clicks from player input since they are extremely important for the feeling of responsiveness. I considered not queuing them but theyre too expensive not to, suffering from a death of a thousand cuts performance wise from many many things in the process adding up. Instead clicks are executed at the very start of the next tick, as the first action that SSinput completes, before player movement is processed even.
A few months ago, before I died I was trying to figure out why games at midpop (40-50 people) had non zero and consistent time dilation without maptick being consistently above 28% (which is when the MC stops yielding for maptick if its overloaded). I found it out, started working on this pr, then promptly died. luckily im a bit less dead now
the current MC has a problem: the cost of verbs is completely and totally invisible to it, it cannot account for them. Why is this bad? because verbs are the last thing to execute in the tick, after the MC and SendMaps have finished executing.
tick diagram2
If the MC is overloaded and uses 100% of the time it allots itself this means that if SendMaps uses the amount its expected to take, verbs have at most 2% of the tick to execute in before they are overtiming and thus delaying the start of the next tick. This is bad, and im 99% sure this is the majority of our overtime.
Take Click() for example. Click isnt listed as a verb but since its called as a result of client commands its executed at the end of the tick like other verbs. in this random 80 pop sybil round profile i had saved on my computer sybil 80 pop (2).txt /client/Click() has an overtime of only 1.8 seconds, which isnt that bad. however it has a self cpu of 2.5 seconds meaning 1.8/2.5 = 72% of its time is overtiming, and it also is calling 80.2 seconds worth of total cpu, which means that more than 57.7 seconds of overtime is attributed to just /client/Click() executing at the very end of a tick. the reason why this isnt obvious is just because the verbs themselves typically dont have high enough self cpu to get high enough on the rankings of overtiming procs to be noticed, all of their overtime is distributed among a ton of procs they call in the chain.
Since i cant guarantee the MC resumes at the very start of the next tick due to other sleeping procs almost always resuming first: I time the duration between clicks being queued up for the next tick and when theyre actually executed. if it exceeds 20 milliseconds of added latency (less than one tenth the average human reaction time) clicks will execute immediately instead of queuing, this should make instances where a player can notice the added latency a vanishingly small minority of cases. still, this should be tm'd
* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* [s] Cleanup escalation unsafe procs (#61905)
Fixes admins spawning in atoms and datums without the DF_VAR_EDITED flag
* [s] Cleanup escalation unsafe procs
Co-authored-by: Jordan Brown <Cyberboss@users.noreply.github.com>
* Fixes some bad addtimers
* Adds INVOKE
* Warning for addtimer
* Working syntax
* Another bad call
* Fixes the addtimer warning
* Add suppress_zero_warning to addtimer
Useful for addtimer that uses vars
* Add INVOKE_AGAIN for when the var is already defined
* Replace addtimer(...,0) with INVOKE((...))
* Much more sensible syntax
* Less overhead, less copypaste
* Rename INVOKE_ASYNC
* Use a macro
* Allman style
* Wait, why make it a datum in the first place?
* Revert the rename
* Rename again, keep line endings
* typo
* More typos
* Untouches Addtimer
* Update callbacks.dm
* Update timer.dm
* Revert allman style
* Revert "Revert allman style"
This reverts commit 47361da15bd04eca138be5f13acdc9dd5ba89331.
* Trying to match that whitespace diff
* Why is this missing?
* I'm not fucking dealing with this!
* SSthrowing + callbacks!
Throwing is now a subsystem.
It's low priority, but is a ticker subsystem so is ran before most other subsystems.
To allow for shit to run after the throw finishes, throwing now supports a callback.
A callback datum system was created, conversion of addtimer is planned for another PR.
Throwing now has a limit of 2048 turfs (was 600)
Throwing now ticks every world.tick, and properly converts the speed arg from 1ds to what ever tick_lag is.
Throwing now properly accounts for missed ticks.
Throwing no longer uses sleep.
Throwing should no longer lag since it's not filling the sleep queue up
* Smoother tentacles
* Some improvements
* Missed a spot.
* Makes shit quicker.
Inlines the thrownthing.tick() proc.
Raises missed ticks value
Lowers max dist value
Inlines the two sister overrides for /atom/movable/Moved() because that just seemed like a waste
* >PRs open that use procs i'm removing.
* STOP THE PRESSES!
* throw_at now runs the first throw tick() immediately
This will help some with throwing while running.
* Item throwing now imparts the momentum of the user throwing.
(ie, running in the direction you are throwing makes you throw faster, running away from the direction you are throwing makes you throw the item slower)
* Moves throwing momentum from carbon/throw_item to movable/throw_at.
There are other things that cause a mob to "throw" an item, I figured we keep this universal since thrower is already an arg.
* Explosions throw shit faster.
This was stupid, "Hey, lets set the item's throw_speed to 4 so embedding works, but lets make it throw at the base 2 throw speed for no reason."
* Fixes explosion embedding.
This also acts as a nice example of how to override a callback in an override of throw_at properly.
