On 30 March 2012 21:52, Guido van Rossum <gu...@python.org> wrote: > Oh dear. I really want to say that 15 ms is good enough. Some possible > exceptions I can think of: > > - Profiling. But this really wants to measure CPU time anyways, and it > already uses a variety of hacks and heuristics to pick the best timer, > so I don't really care.
That depends on what you're profiling. If you're profiling CPU bound algorithms then yes CPU time is better. But if your trying to profile/measure hardware device/comms performance for example then CPU time is of no interest. There, on windows the 15ms resolution of time.time makes it useless. For some reason I always forget this and sit looking at trace outs for 5 minutes wondering why everything takes either 0, 15, or 30ms. For nearly all my use cases I'm not terribly interested in monotonicity, or stability in suspend/resume states so I won't give my opinions on thiose (though I can see they are good things and can well imagine needing them one day), I just want an easy way of getting at least micro second resolution cross platform. I don't mind particularly what you call it but FWIW 'highres' seems a bit odd to me. It seems that highres is likely to seem lowres one day, and then you need to add higherres() and then evenhigherthanthatres(). I would go with microtime(), or nanotime() it doesn't make any promises about anything other than the resolution. Sam _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
