The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

Chris Angelico rosuav at gmail.com
Sat Mar 12 10:30:45 EST 2016


On Sun, Mar 13, 2016 at 2:12 AM, BartC <bc at 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



More information about the Python-list mailing list