Wireshark-dev: Re: [Wireshark-dev] Tips regarding measuring function execution times
On Oct 14, 2017, at 7:18 AM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> 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.
