[Greg Ewing] >> Is there still an intention to get rid of centralised >> coercion and move it all into the relevant methods? [Guido] > 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.
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