Message62869
> 1. .. It's preferable to cast into a clock_t immediately rather than
> doing a conversion for each of the ensuing divisions.
If that's your motivation, then you should cast to double instead.
However, I would leave it to compiler to do micro-optimizations like
these. I am not aware of a standard that says that clock_t must be wider
than long. I agree that it is unlikely to produces wrong results given
that we are realistically talking about 50-1000 range, but on some
platforms you may see a warning.
> 2. .. Is that -1 return value documented somewhere?
Yes, see man sysconf on a sufficiently unix-like system or http://www.opengroup.org/onlinepubs/009695399/functions/sysconf.html
> 4. You're right about the overhead, but someone (amk?) measured it and
> it's only 5% compared to the old buggy behaviour. It's still possible
to
> do a million calls to os.times() from Python in a second, which is
> plenty fast enough. Clearly the speed could be improved, but it
> doesn't appear worth the complications to me.
5% is a lot and IIRC os.times is used by some standard python profilers
and 5% slowdown will affect people.
What I suggest is a simpler solution than your patch:
(1) Define USE_SYSTEM_HZ in config.h (will require some autoconf
hacking).
(2) Define Py_HZ as system HZ on the systems where HZ can be trusted.
(Some systems already define HZ as sysconf(_SC_CLK_TCK)) and fix the
system definition appropriately where necessary.
(3) Replace HZ with Py_HZ in posixmodule.c
The advantage is that the systems where os.times is not broken will not
be affected.
BTW, does anyone know if sysconf(_SC_CLK_TCK)) result can change during
process lifetime? |
|
Date |
User |
Action |
Args |
2008-02-24 02:40:05 | belopolsky | set | spambayes_score: 0.00246032 -> 0.0024603216 recipients:
+ belopolsky, gvanrossum, maltehelmert, pitrou, rbp |
2008-02-24 02:40:05 | belopolsky | set | spambayes_score: 0.00246032 -> 0.00246032 messageid: <1203820805.72.0.03198280632.issue1040026@psf.upfronthosting.co.za> |
2008-02-24 02:40:04 | belopolsky | link | issue1040026 messages |
2008-02-24 02:40:03 | belopolsky | create | |
|