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 maltehelmert
Recipients belopolsky, gvanrossum, maltehelmert, pitrou, rbp
Date 2008-02-24.15:29:43
SpamBayes Score 0.00047432355
Marked as misclassified No
Message-id <1203866985.51.0.557317114256.issue1040026@psf.upfronthosting.co.za>
In-reply-to
Content
Alexander, speed-wise your patch is worse than the original one on
systems where HZ isn't predefined, because it calls sysconf 5 times in
each call to os.times, rather than only once per call.

If you worry about speed, the approach outlined in Antoine's last
message makes most sense to me. Doing this in the configure script
appears dangerous to me; it is well possible that the clock tick value
changes over time on the same machine (e.g. after a kernel upgrade), so
this should be determined upon process initialization, not before
compilation.

Also, I don't think that the HZ value should be preferred to the sysconf
value if both are available, as all times man pages I could check
mention sysconf as the correct way to do this, not HZ. (Some of them
state that HZ is used on "older systems".)

Finally, your patch assumes that HAVE_TIMES implies HAVE_SYSCONF; is
that guaranteed? In particular, it's not clear to me what happens on
Windows (see comment at the top of the file). I also have no idea how
any of the earlier patches behaves on Windows, unfortunately.
History
Date User Action Args
2008-02-24 15:29:45maltehelmertsetspambayes_score: 0.000474324 -> 0.00047432355
recipients: + maltehelmert, gvanrossum, belopolsky, pitrou, rbp
2008-02-24 15:29:45maltehelmertsetspambayes_score: 0.000474324 -> 0.000474324
messageid: <1203866985.51.0.557317114256.issue1040026@psf.upfronthosting.co.za>
2008-02-24 15:29:44maltehelmertlinkissue1040026 messages
2008-02-24 15:29:44maltehelmertcreate