[Python-Dev] Silly little benchmark
Thu, 12 Jul 2001 23:27:32 -0400
>> 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
> 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.