add time.monotonic() method

@doko42

BPO	10278
Nosy	@doko42, @abalkin, @pitrou, @kristjanvalur, @vstinner, @merwok, @briancurtin, @anacrolix, @4kir4, @vadmium
Files	wallclock.patch monotonic.py clock_gettime.patch wallclock-2.patch wallclock-3.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/vstinner'
closed_at = <Date 2012-01-18.21:39:43.081>
created_at = <Date 2010-11-01.15:10:08.663>
labels = ['interpreter-core', 'type-feature']
title = 'add time.monotonic() method'
updated_at = <Date 2019-02-20.10:34:21.980>
user = 'https://github.com/kristjanvalur'

bugs.python.org fields:

activity = <Date 2019-02-20.10:34:21.980>
actor = 'vstinner'
assignee = 'vstinner'
closed = True
closed_date = <Date 2012-01-18.21:39:43.081>
closer = 'pitrou'
components = ['Interpreter Core']
creation = <Date 2010-11-01.15:10:08.663>
creator = 'kristjan.jonsson'
dependencies = []
files = ['19455', '19461', '23083', '23799', '23809']
hgrepos = []
issue_num = 10278
keywords = ['patch']
message_count = 40.0
messages = ['120130', '120131', '120141', '120144', '120146', '120149', '120153', '120154', '120192', '120193', '120205', '120207', '126223', '126248', '126274', '139965', '142792', '143205', '143206', '143209', '143364', '146349', '146351', '146355', '146357', '148523', '148530', '148596', '150861', '150888', '150938', '151504', '151506', '151559', '151570', '151666', '151858', '155819', '155826', '336059']
nosy_count = 12.0
nosy_names = ['doko', 'belopolsky', 'pitrou', 'kristjan.jonsson', 'vstinner', 'eric.araujo', 'brian.curtin', 'glenn', 'anacrolix', 'akira', 'python-dev', 'martin.panter']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue10278'
versions = ['Python 3.3']

If measuring time across blocking calls, such as thread synchronization, one currently must time.time(). This is because time.clock() measures cpu seconds on unix. On windows, however, time.clock() would be more appropriate because it measures wall-clock time.

To avoid having to put platform clauses everywhere, this patch adds time.wallclock().
The current implementation is a simple alias to time.clock on windows and time.time otherwise. Future improvements may add a better implementation on those non-windows platforms that support it.

+1

Why does this need to be in stdlib?

AFAICT, the proposed patch is just:

if <appropriate test>:
   wallclock = time.clock
else:
   wallclock = time.time

which is easy enough to stick in your measuring code or a project's utilities module.

If others really want to see this in stdlib, I would prefer to place it in a more specialized module such as profile.

Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would be useful for the stdlib to provide the right tool for the job.
As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.

On Mon, Nov 1, 2010 at 1:43 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..

Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
be useful for the stdlib to provide the right tool for the job.

This sounds like an argument against this feature, not for it. If it
is hard for the application code to implement an appropriate test "a
priori", what is the chance to get it right in stdlib?

As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.

Having time.time and time.clock is already confusing enough. Having
the third function which is either the first or the second depending
on some unspecified criterion does not strike me as a clean design.

> Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
> be useful for the stdlib to provide the right tool for the job.

This sounds like an argument against this feature, not for it. If it
is hard for the application code to implement an appropriate test "a
priori", what is the chance to get it right in stdlib?

The point of a standard library is to bring together competence and
experience to build a common ground of useful functions. If we
restricted ourselves to easy things then 75% of the stdlib should be
ripped out.

> As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.

Having time.time and time.clock is already confusing enough. Having
the third function which is either the first or the second depending
on some unspecified criterion does not strike me as a clean design.

The problem is time.clock(), since it does two wildly different things
depending on the OS.
I would suggest to deprecate time.clock() at the same time as we add
time.wallclock(). For the Unix-specific definition of time.clock(),
there is already os.times() (which gives even richer information).

On Mon, Nov 1, 2010 at 2:09 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..

> > Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
> > be useful for the stdlib to provide the right tool for the job.
>
> This sounds like an argument against this feature, not for it. If it
> is hard for the application code to implement an appropriate test "a
> priori", what is the chance to get it right in stdlib?

The point of a standard library is to bring together competence and
experience to build a common ground of useful functions. If we
restricted ourselves to easy things then 75% of the stdlib should be
ripped out.

It looks like I misunderstood what you said. I thought "a priory"
meant without knowing the details of the application rather than "by a
novice."

On Mon, Nov 1, 2010 at 2:09 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..

The problem is time.clock(), since it does two wildly different things
depending on the OS.
I would suggest to deprecate time.clock() at the same time as we add
time.wallclock(). For the Unix-specific definition of time.clock(),
there is already os.times() (which gives even richer information).

+1, but doing something like that should be discussed on python-ideas
first. We should also weigh this against other proposals such as
exposing gettimeofday.

Certainly.
I was going to put this simple code in time.py when I realized that time was a C module.

The main point, as Antoine points out, is that time.clock() means two seriously different things on the two main platforms, and time.clock() is potentially inadequate on one of them.

I put in the patch since it was quick to do, but I'll provoke a discussion on python-ideas for now.

2010/11/1 Kristján Valur Jónsson <report@bugs.python.org>:
..

I put in the patch since it was quick to do, but I'll provoke a discussion
on python-ideas for now.

I am looking forward to it. You may find reviewing the following
issues helpful for your case: bpo-9079, bpo-2736, and bpo-9528.

I would also be nice to have a "monotonic" clock in Python. See monotonic.py for an example. But I don't know if it solves the same problem than time.wallclock() or not. I need a monotonic clock for a server on which NTP is sometimes called to resynchronize the system clock (and the NTP server may be change by the user).

Well, that is sort of what I'm trying to achieve. Note that you probably want to use QueryPerformaceCounter on windows (or simply time.clock()) or at least GetTickCount64 which doesn't wrap around after 50 days :). Also, I'm trying to get the highest resolution possible...

I agree with Victor: Python should provide a function to supply monotonic time, which is what's really wanted for measuring time deltas. Far too many applications incorrectly use the system clock for this, and Python makes this worse by not providing any standard library function to allow people to do this correctly.

In Windows, it should probably use GetTickCount64 if available, otherwise GetTickCount with logic to handle wrapping. I think QueryPerformanceCounter is problematic as a general-purpose timer: depending on the hardware and Windows version, it can be offset differently across CPUs, and may not be reliable on some processors. It may be fixed in Vista or Win7, I'm not sure; if so it's much higher resolution than GTC.

New changeset bb10cd354e49 by Victor Stinner in branch 'default':
Close bpo-10278: Add time.wallclock() function, monotonic clock.
http://hg.python.org/cpython/rev/bb10cd354e49

New changeset 1de276420470 by Victor Stinner in branch 'default':
Issue bpo-10278: fix a typo in the doc
http://hg.python.org/cpython/rev/1de276420470

There are some issue on the Windows buildbots:

======================================================================
FAIL: test_wallclock (test.test_time.TimeTestCase)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_time.py", line 340, in test_wallclock
    self.assertAlmostEqual(t, 0.1, places=2)
AssertionError: 0.09138312271531701 != 0.1 within 2 places

New changeset 83e8c3a6a81c by Antoine Pitrou in branch 'default':
Be more lenient in test_wallclock (issue bpo-10278).
http://hg.python.org/cpython/rev/83e8c3a6a81c

New changeset 8502a9236c2e by Victor Stinner in branch 'default':
Issue bpo-10278: Be more explicit in tests than wallclock() is monotonic (cannot
http://hg.python.org/cpython/rev/8502a9236c2e

New changeset fb0f4fe8123e by Victor Stinner in branch 'default':
Issue bpo-10278: wallclock() cannot go backward, but two consecutive calls
http://hg.python.org/cpython/rev/fb0f4fe8123e

New changeset c11946846474 by Victor Stinner in branch 'default':
Issue bpo-10278: Drop time.monotonic() function, rename time.wallclock() to time.steady()
http://hg.python.org/cpython/rev/c11946846474

New changeset 27441e0d6a75 by Victor Stinner in branch 'default':
Issue bpo-10278: Add an optional strict argument to time.steady(), False by default
http://hg.python.org/cpython/rev/27441e0d6a75

This issue has been followed by the PEP-418 which added time.monotonic(), time.perf_counter() and time.process_time().

Navigation Menu

Repository navigation

add time.monotonic() method #54487

20 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

add time.monotonic() method #54487

Description

Activity

kristjanvalur commented on Nov 1, 2010

voidspace commented on Nov 1, 2010

abalkin commented on Nov 1, 2010

pitrou commented on Nov 1, 2010

abalkin commented on Nov 1, 2010

pitrou commented on Nov 1, 2010

abalkin commented on Nov 1, 2010

abalkin commented on Nov 1, 2010

kristjanvalur commented on Nov 2, 2010

abalkin commented on Nov 2, 2010

vstinner commented on Nov 2, 2010

kristjanvalur commented on Nov 2, 2010

glenn commented on Jan 14, 2011

20 remaining items

python-dev commented on Jan 18, 2012

python-dev commented on Jan 18, 2012

pitrou commented on Jan 18, 2012

python-dev commented on Jan 18, 2012

python-dev commented on Jan 20, 2012

python-dev commented on Jan 23, 2012

python-dev commented on Mar 14, 2012

python-dev commented on Mar 15, 2012

vstinner commented on Feb 20, 2019

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions