You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firstly, thanks a lot for this lib which is a very convenient wrapper for managing perf counters from Go clients.
I have noticed that the way TimeRunning and TimeEnabled counters are exposed for different profilers is inconsistent. Infact each event keeps track of its own running and enabled times as rightly implemented here. However, when a process is being profiled this information is wrongly presented.
Take an example of HardwareProfiler where TimeEnabled and TimeRunning is set to one of the event's times values and ignoring the times values of the rest of events. Moreover profilers is a map where order is undefined. So, the first time we profile, we might get times of CPUCyles where as the second profiling might returns the times of CPUInstr. In my tests, I have noticed that the times for different events can be different enough to break the monotonicity. Thus, we cannot scale the multiplexed values consistently.
A solution might be to export ProfileValue for each event instead of just ProfileValue.Value? In that way, times of each event are exported and we can scale them consistently.
The text was updated successfully, but these errors were encountered:
Hello,
Firstly, thanks a lot for this lib which is a very convenient wrapper for managing
perf
counters from Go clients.I have noticed that the way
TimeRunning
andTimeEnabled
counters are exposed for different profilers is inconsistent. Infact each event keeps track of its own running and enabled times as rightly implemented here. However, when a process is being profiled this information is wrongly presented.Take an example of
HardwareProfiler
whereTimeEnabled
andTimeRunning
is set to one of the event's times values and ignoring the times values of the rest of events. Moreoverprofilers
is a map where order is undefined. So, the first time we profile, we might get times ofCPUCyles
where as the second profiling might returns the times ofCPUInstr
. In my tests, I have noticed that the times for different events can be different enough to break the monotonicity. Thus, we cannot scale the multiplexed values consistently.A solution might be to export
ProfileValue
for each event instead of justProfileValue.Value
? In that way, times of each event are exported and we can scale them consistently.The text was updated successfully, but these errors were encountered: