Chris Angelico <ros...@gmail.com> writes: [...] > The only actual data I have on the subject is the perfect-numbers > search the other day; Pike managed the same task in a fraction of the > time that Python spent on it. Pike has a single integer type that > quietly switches from small to large at 2**32, with a noticeable > performance change. This is the same as Python 2, but could explain > some of the Python 3 penalty. There's only two obvious possibilities > (there may be others, of course): firstly, that the actual name lookup > is expensive; and secondly, that Pike is able to optimize integer > arithmetic by knowing that the value in question is an int, and it > will never be anything else.
Pike is (at least partly) statically typed. Most of the lookups are solved at compile time, and have therefore zero overhead at run-time. So your second possibility is the good one, but probably not because of arithmetic optims, rather because of all the lookups Pike doesn't perform dynamically. -- Alain. -- http://mail.python.org/mailman/listinfo/python-list
