On Mon, Apr 2, 2012 at 2:31 AM, Sam Partington <sam.parting...@gmail.com> wrote: > 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.
You're being altogether too reasonable about it. :-) People keep asking for a clock that has nanosecond precision and yet will tell time accurately for centuries, without ever skipping forward or backward... -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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