On Wed, Apr 1, 2015 at 12:42 AM, Christian Peel <sanpi...@gmail.com> wrote:
> I'm looking to time parts of a program using libuv commands.  I call one of
> the following time commands before and after a chunk of code is run and take
> the difference to get the time for the code.  My goal is to find a time
> metric which isn't influenced by the load on the machine while executing the
> code. Here are some options in libuv with links to libuv code:
> * Use uv_hrtime, which returns clock time with nanosecond resolution.  In
> linux, this calls clock_gettime; I'm not certain how important the _COARSE
> business is or not  http://bit.ly/1DorhB0
> * Use uv_getrusage, which returns user and system time with microsecond
> resolution. In linux, this eventually calls task_utime and task_stime
> http://fla.st/1Ff7umH
> * Finally, I can call uv_cpu_info, which on linux reads from /proc/stat in
> the function read_times. See line 658 of http://bit.ly/1DorhB0
>
> I'm calling libuv from Julia, and am working to check the impact of garbage
> collection.  I don't think there is significant overhead for calling C from
> Julia, but will continue to investigate that. I'm trying to test code that
> is both on the order of tens of us to hundreds of ms. The first two options
> above (uv_hrtime and uv_getrusage) still seem to be influenced by the system
> load on the 32-core machines that I'm testing on.   For uv_rusage I tried
> both the sum of the system and user time and just the user time.    The
> third option (uv_cpu_info) seems heavy since I'm just trying to time short
> chunks of code. Do any of you have suggestions for how to time a short
> section of code in a way that is independent of the system load?
>
> Thanks

If you are actively profiling code, you should really be using
something like perf or oprofile.

If you are passively collecting metrics, use uv_hrtime() for tracking
wall clock time and uv_getrusage() for CPU time.  uv_getrusage() is
also good for tracking metrics like major/minor page faults and
voluntary/involuntary context switches.

I'm not sure what you mean with "seem to be influenced by the system
load".  There is only so much CPU time to go around.  If the system is
overcommitted, something's gotta give, right?

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to libuv+unsubscr...@googlegroups.com.
To post to this group, send email to libuv@googlegroups.com.
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to