Re: Tips regarding measuring function execution times

[Guy Harris <guy () alum mit edu>]

On Oct 14, 2017, at 7:18 AM, Paul Offord <Paul.Offord () 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-request () wireshark org?subject=unsubscribe