On Oct 14, 2017, at 7:18 AM, Paul Offord <paul.off...@advance7.com> wrote:
> I’m investigating a performance problem with the TRANSUM dissector. I’d like > to measure the accumulated time taken to execute a function in a Release > build. My basic idea is to do something like this: ... > Is there a standard way to do this in Wireshark? No. Given that you're checking *CPU* time, you'd do it with getrusage() on UN*X, although note that it has microsecond resolution, so you'd need to accumulate several microseconds worth of CPU time to get reliable results. A quick search found https://github.com/openvswitch/ovs/blob/master/lib/getrusage-windows.c which suggests that the Windows equivalent to getrusage() for getting the current process's CPU time is GetProcessTimes(): https://msdn.microsoft.com/en-us/library/windows/desktop/ms683223%28v=vs.85%29.aspx with the result of GetCurrentProcess() passed as the first argument. It has .1 microsecond resolution. That MSDN page also lists QueryProcessCycleTime(): https://msdn.microsoft.com/en-us/library/windows/desktop/ms684929(v=vs.85).aspx which returns a value in units of "CPU clock cycles", with the duration of a "CPU clock cycle" unspecified; on x86, it's probably what the Time Stamp Counter deals in. Since you're trying to determine relative CPU times, you probably don't need to know how much time a "CPU clock cycle" is, you just need to know whether one measurement is greater than another measurement, e.g. "how much of the CPU time is being spent in X vs. spent in Y?" or "am I spending significantly less CPU time after this change?" > How can I output the accumulated time on, say, the Status Line? If this is just trying to figure out why bug 14094 is happening, e.g. is find_latest_rrpd() at fault or not, it might be possible to handle this with TShark, as suggested by Peter Wu. Or perhaps the "CPU Usage" tool: https://msdn.microsoft.com/en-us/library/dn971856.aspx is what should be used here - that might tell you what *is* at fault. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe