Fredrik Lundh wrote: > if I run this on the Windows 2K box I'm sitting at right now, it settles > at 100 for time.time, and 1789772 for time.clock. on linux, I get 100 > for time.clock instead, and 262144 for time.time.
Aren't the time.clock semantics different on 'nix? I thought, at least on some 'nix systems, time.clock returned a "cpu time" value that measured actual computation time, rather than wall-clock time [meaning stalls in IO don't count]. This is pretty easily confirmed, at least on one particular system (interactive prompt, so the delay is because of typing): Python 2.2.3 (#1, Nov 12 2004, 13:02:04) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> (c,t) = (time.clock, time.time) >>> (nowc, nowt) = (c(), t()) >>> print (c() - nowc, t() - nowt) (0.0019519999999999989, 7.6953330039978027) So caevat programmer when using time.clock; its meaning is different on different platforms. -- http://mail.python.org/mailman/listinfo/python-list
