I am using boost python and trying to measure latency of a switch from C++ to python and vice versa. But I think i am doing it wrong, I get the time in C++ by clock_gettime()(t0) and pass it as an argument to python function and from within this function I call time.time()(t1) to get the time. But when I try to measure the latency by doing t1-t0, it is sometimes positive, sometimes negative and sometimes 0. Why is that?
I'd expect this latency to be on the order of nanoseconds so if you want to measure it, it'll important to use an accurate clock and make sure they're consistent. Also understand that at this level actually reading the clock will be a non-negligible cost, so it might not be a realistic goal in the first place.
For python 3, the underlying C function call is available using time.get_clock_info
On my system, time.time() uses clock_gettime(CLOCK_REALTIME)
In [1]: import time
In [2]: time.get_clock_info("time")
Out[2]: namespace(adjustable=True, implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, resolution=1e-09)
That's probably good enough for your purposes, but time.perf_counter(), can have better precision, especially on windows.
If you're stuck on python 2, accoring to the source time.time() tries to use gettimeofday(), then ftime() then time(). Since windows doesn't have gettimeofday, it will use ftime for at most millisecond precision, and on *nix, gettimeofday only has microsecond precision.
On windows you might be able to use time.clock(), which uses QueryPerformanceCounter(), but on linux, it uses clock(), which is also usually only microsecond precision, so likely doesn't have enough precision either.
You could maybe try a different strategy, and time the complete execution of an empty python function using clock_gettime, or the difference between two python calls to a boost wrapper for clock_gettime(), which will at least get an upper bound. You could also time a million empty function calls or something to eliminate some of the cost of querying the time.