[Skip Montanaro] > I wasn't suggesting you weren't trustworthy. Neither was I <wink>. > On a Linux system, wall clock time doesn't mean much when timing > processes. Sure -- different OS. I'm not telling you how to time things on Linux; I just explained what I did on Windows because it was questioned. > ... (does Windows even distinguish between user and system time?). I've never seen anything in Win9x that does, and not surprised: they're at best <0.7 wink> single-user systems. On NT there's an elaborate performance monitoring subsystem tied to the HKEY_PERFORMANCE_DATA registry hive, from which-- given enough programming pain, none of which Python endures --you can find out almost anything. > That time.clock means different things on Windows and Unix-like systems > bothers me a bit. Blame X3J11 -- ANSI C is vague about what clock() is supposed to do. I've got no use for the *native* Windows implementation of clock() (Python maps time.clock() to the high-resolution Win32 QueryPerformanceCounter API instead); Unices in general don't have usable high-resolution timers; Windowses in general don't have usable notions of user process time; so we take what we can get. > (It would bother me more if I had to write timing code that was > portable across both Unix and Windows.) Hmm. Unless you're happy with wall-clock time, it may well drive you insane just to write timing code portable across Unices. At my last employer, we wrote all our base timing routines in assembler, because it's generally easy to suck what you need out of modern HW, but darned near impossible after seventeen warring stds committees finish taking turns hiding it <wink>. [about BINARY_ADD slowing string+string] > I can buy that. Wasn't there some discussion about improving this > situation? Yes. > If so, I guess I should be using the head branch of the CVS tree > instead of release21-maint. AFAIK, nobody did anything *except* discuss it so far. Insert an early special case for sequence cat, and you slow each numeric addition by the time it takes to fail that test, so there's no killer argument either way. int+int is special-cased by BINARY_ADD, but everything else goes thru the general machinery.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4