On Sun, Mar 13, 2016 at 2:12 AM, BartC <b...@freeuk.com> wrote: > 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).
Or maybe they're all actually *object* comparisons, and what you know about assembly language has no relationship to what's going on here. This is why we keep advising you to get to know *Python*, rather than trying to use it as "assembly language with different syntax", especially when you start making performance estimates. Even with C code, I've stopped trying to predict what performance will be. (I'm not sure whether I could guess at assembly language performance; I stopped writing any at all when C compilers got provably better than me in all circumstances - which happened a good while ago.) The ONLY way to know whether X is faster than Y is to try them both. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
