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