This is probably a low priority issue compared many other bugs/feature requests. But one of the major challenges of lowering tick_lag is that some procs have the following characteristics -
- they do not use a very large amount of cpu normally
- they also do not use a large amount of cpu on average
- however, their cpu usage can peak out much higher than their normal average cost and often overrunning a tick causing a noticeable spike of latency for all players in the game
Therefore, it would be useful for the profiler to be capable of logging a peak cost of self cpu in a separate column, or if feasible and time constraints willing, a ticked box like average that records the peak self cpu, total cpu, realtime of the procs.
This would allow optimization or management of procs that cause intermittent and unpredictable lag spikes since they would normally appear to be using a normal cpu usage and average cpu usage and not be caught while attempting to profile.
ID:1928671
 Aug 31 2015, 9:31 pm
|
|||||||
| |||||||
|
Aug 31 2015, 9:59 pm
|
|
Lummox JR
   |
Hmm. That's an interesting idea. Peak cost could be useful info--as could variance.
|
Peak would be per-tick, right? Even merely counting the # of ticks a proc was called in would be fantastic for helping identify problems before they become catastrophic.
| |
No, peak would be per call.
| |
That won't be useful at all though
The idea is knowing "Is this proc being called 500,000 times in one tick or 500,000 times in 500,000 ticks?" | |
Clusterfack's suggestion was simply per call, and I do think it'd be quite useful based on his description. It would also be feasible, which per-tick would not be.
| |
Yes the point of my suggestion is to identify problem procs that would slip under the radar when profiling because they do not have a high average cost, but do under specific instances that a person profiling now would not be able to detect besides manually clearing and profiling a smaller subset of time which is not feasible.
While the profiler gives great information about a large average time, if someone stresses certain ingame functions to a breaking point such that they cause latency it is critical to know where and what these procs are so that their scope can be limited or that safeties can be installed into them. | |
Bump
| |
I support this though, as I'm just now seeing it. | |
I was looking into profiling features since I wanted to make a request myself.
| |
open source byond when
| |
This can't be bumped enough!
| |
No it can not.
| |
Yes, please
| |