Chrome trace timestamp should be in microseconds not seconds.

[sklam]

Fix #8599.

[stuartarchibald]

Thanks for the patch.

A potentially important side discussion is needed here as I don't think this is necessarily always a question of scaling microseconds to seconds. From the code, it looks like the timer used in the event module is based on timeit.default_timer. From the python docs, timeit.default_timer is always time.perf_counter, which doesn't seem to guarantee the unit of the returned value, it's just "the clock with the highest available resolution". This means the resolution needs to be known to work out an appropriate scaling factor to get to the unit of seconds.

I think there's two options:

1. Use time.perf_counter_ns for timing, time would then always be reported in nanoseconds and scaling to seconds would always be via a constant factor. This also has the advantage of not losing precision through the use of a float type as the returned value.
2. Continue to use timeit.default_timer i.e. time.perf_counter. Then query time.get_clock_info('perf_counter') to get the resolution of the timer, the inverse of which is the scaling to get to the unit of seconds.

Any thoughts @sklam ?

[sklam]

@stuartarchibald, even though timeit.default_timer has unknown resolution but it is always in the unit of seconds. The new doc now say defaut_timer is always time.perf_counter which has Return the value (in fractional seconds) of a performance counter.

The tracing format expect a float type in microseconds unit anyway so i don't think the loss of precision matter that much. And, Numba is not that fast.

[stuartarchibald]

@stuartarchibald, even though timeit.default_timer has unknown resolution but it is always in the unit of seconds. The new doc now say defaut_timer is always time.perf_counter which has Return the value (in fractional seconds) of a performance counter.

The tracing format expect a float type in microseconds unit anyway so i don't think the loss of precision matter that much. And, Numba is not that fast.

Thanks! Following some OOB discussion, turns out this is all ok. The issue is that the tracer output needs to be in microseconds and the clocks are reporting in seconds even if not explicitly noted, so the scale factor is constant and there's no resolution issue or otherwise!

[stuartarchibald]

Thanks for the updates, changes look good. @guilhermeleobas did you perhaps want to test this as in #8599 ?

[guilhermeleobas]

Thanks, I can confirm the fix solves the original issue.

[stuartarchibald]

Thanks for confirming @guilhermeleobas !