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