Message148392
| Author |
neologix |
| Recipients |
georg.brandl, neologix, pitrou |
| Date |
2011年11月26日.11:12:41 |
| SpamBayes Score |
7.3496764e-14 |
| Marked as misclassified |
No |
| Message-id |
<1322305961.91.0.187968883224.issue13481@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> Indeed. I thought CPU time would be more useful (and that's the point
> of the patch)
Ah, OK.
Then you should probably rename the issue "make timeit measure CPU time", or something like that, because I really thought this issue was about using a more accurate clock (less jitter, can't go backward, etc). And also update the documentation :-)
> but perhaps it breaks the spec.
Well, I almost never use timeit so I can't make a call, but that's definitely a semantics change, and this may puzzle some users, especially since it will really depend on the OS/kernel version in use (and so it won't be documented).
> But does it include kernel CPU time for the given process?
Yes. But it won't be reliable, for example, to measure the performance of a new readinto() implentation, since time spent by the process in 'S' or 'D' state won't be accounted for. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年11月26日 11:12:42 | neologix | set | recipients:
+ neologix, georg.brandl, pitrou |
| 2011年11月26日 11:12:41 | neologix | set | messageid: <1322305961.91.0.187968883224.issue13481@psf.upfronthosting.co.za> |
| 2011年11月26日 11:12:41 | neologix | link | issue13481 messages |
| 2011年11月26日 11:12:41 | neologix | create |
|