This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients Arfrever, lemburg, neologix, pitrou, python-dev, vstinner
Date 2012-04-30.06:56:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1_TcOSG45QSNuG9ic_cdnrCP4u3e7kUX1jXkco5pKPLA@mail.gmail.com>
In-reply-to <1335743642.42.0.704235430298.issue14428@psf.upfronthosting.co.za>
Content
> Yes, dt is not a number of seconds in the following example:
>
> t1=time.process_time(); (...); t2=time.process_time(); dt=t2-t1

OK, so what is it then?
It's not written anywhere - neither in the PEP nor in the
documentation - and it should.

Furthermore:
"""
$ cat /tmp/test_ptime.py
import sys
import time

rt = time.time()
pt = time.process_time()

for i in range(int(sys.argv[1])):
    pass

print("real time: %f" % (time.time() - rt))
print("process time: %f" % (time.process_time() - pt))
$ ./python /tmp/test_ptime.py 100000
real time: 0.168570
process time: 0.168425
"""

It really looks like seconds to me, definitely not jiffies ;-)
Also, I've had a quick look at the code, and ISTM that it does indeed
return seconds.

> I wrote the test to check if time.process_time() measures the total CPU of
> the process, and not the CPU time of only the current thread.
>
> I'm tired of this PEP, so I just removed the test. I don't think that it is
> really interesting and it looks difficult to write a reliable test.

Hum, right now, the only process_time test I see is test_process_time,
which just checks that a sleep almost doesn't consume "process time",
which is a bit light.

"""
        # Use a factor of 0.75 because time.process_time() is maybe not precise
        self.assertGreaterEqual(t2 - t1, busy * 0.75)
"""

It's not that process_time() is not precise (I assume you mean accurate ;-).
It's just that since it measures CPU time (user+system), it depends on
the scheduling: in fact, if you have let's say a real-time priority
task running at the same time, on a uniprocessor system, the thread
could in theory not even get a chance to run, which would yield a CPU
time of 0: that would still be accurate.
History
Date User Action Args
2012-04-30 06:56:40neologixsetrecipients: + neologix, lemburg, pitrou, vstinner, Arfrever, python-dev
2012-04-30 06:56:40neologixlinkissue14428 messages
2012-04-30 06:56:39neologixcreate