On 12/03/2016 12:10, Chris Angelico wrote:
On Sat, Mar 12, 2016 at 10:08 PM, BartC <b...@freeuk.com> wrote:
Writing: a=65 generates this byte-code for the right-hand-side: LOAD_CONST 1 (65) An integer But writing instead: a=ord('A') generates this: LOAD_GLOBAL 0 (ord) LOAD_CONST 1 ('A') A string CALL_FUNCTION 1I think the "non-issue" here is the difference between ASCII and Unicode. Either way, there's no way to say "the integer with the codepoint of this character" as a literal. But that's actually not even all that necessary, because subscripting a text string yields one-character strings - you almost never need the ordinals.
That explains why you rarely use integers, if you prefer to use strings even when there is a choice!
However, I was going to revise my benchmark to use strings instead of integers, to show how much slower they would be. But the program was 10% faster with strings!
I don't know what to make of that. Clearly comparing an integer with an integer is a very fast operation, or ought to be, while comparing strings is much less efficient at machine level.
So there's something funny going on. Either string operations are super-fast or integer operations are somehow crippled. Or maybe there so many other overheads, that the difference between strings and ints is lost.
That doesn't explain why ints are slower though (and this was the case even on Python 2 where the 'long' type is not involved).
-- Bartc -- https://mail.python.org/mailman/listinfo/python-list
