<br><br><div><span class="gmail_quote">On 5/24/06, <b class="gmail_sendername">Tim Peters</b> <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
time.clock() has sub-microsecond resolution (better than a millionth of a second) on all flavors of Windows.<br><br>time.time() has poor resolution on all flavors of Windows, and is extraordinarily expensive to call on some flavors of Windows. The resolution depends in part on HW configuration. Most common are updating
18.2 times per second (0.055 second resolution) or 100 times per second (0.01 second resolution). As a result, if you call time.time() twice in a row on Windows, it's likely you'll get exactly the same value both times.</blockquote>
<div><br>Is there any particular reason we don't implement time.time() in terms of time.clock() (or rather, the same underlying mechanism?) Seed it once with ftime or gettimeofday or whatever's best on Windows, then use the performance counters to keep track of elapsed time? It wouldn't provide more accurate absolute time (and indeed, slightly more inaccurate, depending on howlong it takes between the two calls), but it would provide more accurate time-differences (as far as I understand.)
<br></div></div><br>Or is time.time(), in spite of being extraordinarily expensive, still faster than time.clock()? Or is time.clock() unreasonably bounded?<br><br>Aren't-half-liter-coke-cans-great'ly y'rs,<br>-- <br>Thomas Wouters <
<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!