[Python-Dev] Silly little benchmark

[Jeremy Hylton]

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

[Guido:]
>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).
>
>Small things add up, but I doubt that this is responsible for any
>particular slow-down.

The big change is the coercion work being done in binary_op1(), which
tries to turn strings into numbers in a variety of ways.  BINARY_ADD
calls PyNumber_Add(), which calls binary_op1().  When the binary_op1()
calls fails, it then tries sequence concatenation.

If it were possible for binary_op1() to fail quickly for non-numeric
sequences like strings, we would not see the slowdown for small string
operations.  (I believe that's what the silly little benchmark shows
and what one of the pybench tests shows.)

Jeremy