BeeStation-Hornet
BeeStation-Hornet copied to clipboard
mass qdel proc to replace qdel_in(), batching all qdel timer into a single timer
About The Pull Request
mass qdel proc to replace qdel_in(), batching all qdel timer into a single timer
Bacon didn't like #10178 but I don't like this in fact
This PR is to show the code difference.
Why It's Good For The Game
performacne
Testing Photographs and Procedure
Mainly the same to
- #10178
Changelog
:cl: code: qdel_in() no longer uses addtimer() for each item to qdel. It sends an item to a list with scheduled time assoc item list. /:cl:
Not a huge fan of this PR, seems like unnecessary jank to accomodate bad code, if something wants to delete 100000 items in 1 tick, then it should handle that internally.
Not a huge fan of this PR, seems like unnecessary jank to accomodate bad code, if something wants to delete 100000 items in 1 tick, then it should handle that internally.
It wouldn't be 100,000 items in a tick, but qdel_in()
itself is already expensive because it uses addtimer()
, but also there's no way to handle this internally because qdel_in()
is massively used in everywhere. (but also you closed garbage timer PR)
We really really shouldn't push pressure on addtimer()
because it sucks
This idea is okay, but it has no way to deal with object deletions and the implementation of timers under the hood is actually pretty efficient and effectively is just looping through a list anyway. I don't think this is necessary and I'm not convinced that this will provide large performance improvements.
The issue doesn't come from how SStimer is coded. The issue comes from how the timer system is used to qdel massive amount of stuff. For example, lighting flickering is one of examples that spams qdel timer.
The biggest difference isn't performance, its that the subsystem can't be TICK CHECKED mid-execution which will result in things being deleted on the same tick (rather than being deferred by timers) but it will also allow the subsystem to overrun its tick allocation to do that
the subsystem can't be TICK CHECKED mid-execution
Nope 🔑 Third key locks this.