[Python-Dev] Silly little benchmark

Tim Peters tim.one@home.com
Thu, 12 Jul 2001 23:27:32 -0400

[Greg Ewing]
>> Is there still an intention to get rid of centralised
>> coercion and move it all into the relevant methods?

> This has been done (except for complex).

>> If that were done, wouldn't problems like this go
>> away (or at least turn into a different set of
>> problems)?

> I'm not sure what that remark refers to, actually.
> BINARY_ADD and BINARY_SUBTRACT just test if both args are ints and
> then in-line the work; BINARY_SUBSCRIPT does the same thing for
> list[int].  I don't think it has anything to do with coercions.  When
> the operands are strings, the costs are one pointer deref + compare to
> link-time constant, and one jump (over the inlined code).

It's not BINARY_ADD, it's the PyNumber_Add() called by BINARY_ADD, which,
given two strings, calls binary_op1, which does a few failing tests, then
calls PyNumber_CoerceEx, which fails quickly enough to coerce, and then
pokes around a little looking for number methods, and finally says "hmm!
maybe it's a sequence?".

> Small things add up, but I doubt that this is responsible for any
> particular slow-down.

Jeremy earlier pinned the blame on this for one of the "dramatic" pybench
slowdowns; Skip may or may not have bumped into it again with his "silly
little benchmark" (read the Subject line <wink>).  I doubt it's responsible
for significant real-life slowdowns.