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
I cannot find any way to get the execution time for a process in the current API. Had a look in the source code, and it seems the corresponding values are actually fetched for some platforms, but ignored (or not made available).
As far as I know, the proper way to fetch these values are:
Linux — Returned by getrusage, but only for the currently running process. AFAIK, the only way to fetch the values for any process is to parse /proc/<pid>/stat, but I might be mistaken there.
Mac — Seems to already be fetched by proc_pidinfo into a libc::proc_taskinfo struct which is used to calculate the instant CPU usage.
Windows — Returned by GetProcessTimes in the lpKernelTime and lpUserTime fields.
FreeBSD — Couldn't find any obvious API, perhaps same story as for Linux?
It would be great if these values were also available, as they make it possible to detect excessive CPU usage "after the fact".
The text was updated successfully, but these errors were encountered:
Interesting… I had missed this one. It is very similar, but I don’t think the API should return accumulated CPU use as a percentage. It is easy enough to calculate a percentage from CPU-seconds, but the inverse loses a lot of precision.
I cannot find any way to get the execution time for a process in the current API. Had a look in the source code, and it seems the corresponding values are actually fetched for some platforms, but ignored (or not made available).
As far as I know, the proper way to fetch these values are:
/proc/<pid>/stat
, but I might be mistaken there.libc::proc_taskinfo
struct which is used to calculate the instant CPU usage.lpKernelTime
andlpUserTime
fields.It would be great if these values were also available, as they make it possible to detect excessive CPU usage "after the fact".
The text was updated successfully, but these errors were encountered: