[Python-Dev] Silly little benchmark

[Skip Montanaro]

    Tim> [Skip Montanaro]
    >> Real time doesn't mean much on an operating system that can
    >> juggle multiple tasks, no matter how quiescent you try to make it.

    Tim> If this made any difference in the results I reported, they
    Tim> wouldn't have been reproducible to nearly 3 significant digits.
    Tim> That's why I printed the times for 3 runs of each -- you can trust
    Tim> that I know what I'm doing here. 

I wasn't suggesting you weren't trustworthy.  On a Linux system, wall clock
time doesn't mean much when timing processes.  I have no control over when
sendmail or any of a number of other daemons might wake up to process
something.  Hence, for my purposes in my environment, user mode time (or
user+sys when sys > 0) are more useful than elapsed time (does Windows even
distinguish between user and system time?).  That time.clock means different
things on Windows and Unix-like systems bothers me a bit.  (It would bother
me more if I had to write timing code that was portable across both Unix and
Windows.)  But that, as they say, is a something left for another time.

    Tim> The other thing Jeremy has noted before: string+string is slower
    Tim> than it used to be, because BINARY_ADD now tries oodles of
    Tim> "sophisticated" ways to coerce the operands to numbers before
    Tim> considering it might be asking for a sequence catenation instead.
    Tim> Given that the benchmark pastes together two 1-character strings,
    Tim> this overhead is overwhelming compared to the concatenation work.

I can buy that.  Wasn't there some discussion about improving this
situation?  If so, I guess I should be using the head branch of the CVS tree
instead of release21-maint.

Skip