Why would windows report the time taken to write random number of lines to file with different float-rounding differently than osx?

Question

I have a python script that is writing the objects of a dict to a file. Using 2.7 on windows 10 the duration of writes is being reported as a number of milliseconds with either .0000nnn or .9999nnnn following. I am using python's time library just like this:

import time
logline = ""

def writer(mydict):
   records = 0
   global logline
   lstart_time = time.time()
   for item in mydict:
       some_open_file.write(item)
   dur = time.time() - lstart_time
   logline +=("\t{0:25}transformed {2} records in {1} ms; avg: {3:2.3f} mis per record.\n".format(
              page['name'], (dur*1000), records, (dur/records)*1000000))

for documents in bigdict:
    logline += some_dict['title']
    for x in some_dict['records']:
        writer(x)
    print(logline)

windows

It doesn't happen in osx with 2.7 though. osx output

How does the windows implementation of python handle the time floats differently than osx? Both are 64 bit, both on python 2.7, both have intel core processors, and both have ssds (although that shouldn't matter). So why does windows/python handle floats differently? How can I get windows to show the more precise numbers I get on the macbook?

Some observations: The mac also seems to have greater variance in the time it takes for the writes. While windows seems consistently take 5.7-6μs per write record on average, the mac ranged from 8-24μs. Kinda surprised the 3-4 year old desktop was faster with very similar overall specs, but Im guessing that's because the desktop probably has a much larger l3 cache even though the chip is older and just slightly faster. That is for another forum.

I used 'mic' because μs was throwing all sorts of encoding errors. Instant praise for anyone that corrects that logline assignment to work with μs in any console.

[related comment](http://stackoverflow.com/questions/31352912/python-resolution-of-datetime-now#comment50699705_31352980) — jfs, Dec 25 '15 at 21:49

Mike Müller · Accepted Answer · 2015-12-25T20:25:16.760

3

Always use timeit.default_timer():

import timeit

lstart_time = timeit.default_timer()

dur = timeit.default_timer() - lstart_time

On Windows time.time() is very coarse and often not useful for timing. timeit.default_timer() uses different functions under the hood for Windows and other platforms. In Python 2.7 these are time.clock() under Windows and time.time() for POSIX (Unix, Mac) platforms. On Windows time.clock() has a much better resolution. Unfortunately, on Unix systems time.clock() has a different meaning and returns the CPU since the start of the program.

edited Dec 25 '15 at 20:25

answered Dec 25 '15 at 20:10

Mike Müller

82,630
20
166
161

I think the name `default_timer` used by the `timeit` module is misleading because what the function does is return the current time in seconds expressed as a floating point number. `current_time()` might be better. Regardless, what you say is good advice. – martineau Dec 25 '15 at 21:36
@martineau Yes, good naming is important. Maybe a better name would be `time_stamp` because it can stand for very different things on different platforms. Starting from Python 3.3, you can use `time.perf_counter()`. In fact, `timeit.default_timer()` it is just an alias for it. And the documentation makes clear that is only useful for the difference between time stamps. *The reference point of the returned value is undefined, so that only the difference between the results of consecutive calls is valid.* – Mike Müller Dec 25 '15 at 21:58
I think the intrinsic problem is that the OP isn't using the [`timeit`](https://docs.python.org/2.7/library/timeit.html) module in the first place — because if they had, there wouldn't have been much of a discrepancy since it uses `default_timer()` internally by default. – martineau Dec 27 '15 at 01:06

Why would windows report the time taken to write random number of lines to file with different float-rounding differently than osx?

1 Answers1