You seem to have missed the episode where I explained that caching the last value in order to avoid going backwards doesn't work -- at least not if the cached value is internal to the API implementation.
2012/4/2 Kristján Valur Jónsson <krist...@ccpgames.com>: > > >> -----Original Message----- >> From: python-dev-bounces+kristjan=ccpgames....@python.org >> [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On >> Behalf Of Cameron Simpson >> Sent: 30. mars 2012 21:43 >> There seem to be a few competing features for clocks that people want: >> >> - monotonic - never going backward at all >> - high resolution >> - no steps >> > "no steps" is something unquantifiable. All time has steps in it. What you > mean here is no 'noise'. And this is also never actually achievable. > A clock that ticks forwards, but sometimes stops some and then ticks some > more, is simply a clock with a lower resolution on average than what can be > observed for certain time periods. > > It befuddles me somewhat how complicated you are making all of this. > Simply provide the best high resolution, non-backwards ticking, performance > timer that the platform provides, and don't try to make promises about > unquantifiable things such as 'steps'. > You can do this simply using QPC on windows and enforcing the forward ticking > using a static local. > Simply promise that this is a forward ticking clock with the highest > resolution and lowest noise available for the platform and make no other > guarantees, other than perhaps suggesting that this might not be used > reliably for benchmarking on older os/hardware platforms. > > K > > > -- --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
