[Python-Dev] Silly little benchmark

[Tim Peters]

[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.