We need to autoschedule verbs, tracking their high/low points. They can cause so much overtime for basically no reason. []
This does risk fully consuming the tick, especially combined with normal input. Perhaps we should attempt to spread them out across ticks? unsure. []
I need to drill down into where "Internal" time is being spent. I can't help but feel something is wrong, it could be my graphing software? I am unsure. Honestly just fucking line by line this shit dude []
I am concerned about how much there is and how it seems to align with usage spikes. My gut is it's queuing/dequeuing but that doesn't inherently line up. Might be worth moving loop() to an inner proc so we can account for cost better? unsure
Might need to kill the thresholding in TICK_LIMIT_RUNNING, especially if we're using the "did we enter overtime" school of thought. []
Why are we limiting subsystems to 70% of the tick on ignite? surely this can at least be made more dynamic. []
Sleeping procs should have more in depth controls. []
Need a way to profile JUST sleeping procs. This might be annoying. []
Atmos causes a good amount of overtime on its own. This is I think due to excited groups. airgroups will save me perhaps? []
We already end up in fucked ticks due to queued say()s sometimes, that might also be something we have to delay. []
Why is pathfinder overtiming what []
Subsystem Overtime graph? []
Need to smooth out maptick, particularly on multiz. Load stuff in the background somehow? []
Technically what matters is not the length of the tick, but the time between maptick calls. If all else fails we could hasten the tick immediately following a spike, and then release that "pressure" over time (though it would lead to a lot of dead cpu cycles) []