Why is Python slow
From the linked [lwn] article:<p>&quot;Another example he gave demonstrates the slowness of the C runtime:<p><pre><code>    import itertools
    sum(itertools.repeat(1.0, 100000000))
</code></pre>
That will calculate the sum of 100 million 1.0s. But it is six times slower than the equivalent JavaScript loop. Float addition is fast, as is sum(), but the result is not.<p>Larry Hastings asked what it was that was slowing everything down. Modzelewski replied that it is the boxing of the numbers, which requires allocations for creating objects. Though an audience member did point out with a chuckle that you can increase the number of iterations and Python will still give the right answer, while JavaScript will not.&quot;<p>Reminded me about the excellent talk about Julia:
&quot;Julia: to Lisp or not to Lisp?&quot;
<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dK3zRXhrFZY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dK3zRXhrFZY</a><p>One things he points out early is that both the C99 and the R6RS Scheme spec is 20% numerical. Because correct and (reasonably) fast numbers and arithmetic is actually pretty hard to get right on a computer - if you want to abstract away hardware &quot;short-cuts&quot; and allow for precise arithmetic by default.<p>It will be interesting to see how much type hints (eliminating some of the boxing&#x2F;unboxing) will help python. And if it turns out to really be a good fit for the language -- everyone wants &quot;free&quot; performance, but transitioning to a (even partially) typed language is certainly not &quot;free&quot;.<p>Another point with the above loop, is that ideally, even if it can&#x27;t be optimized&#x2F;memoized down to a constant - it really shouldn&#x27;t have to be much slower than its C counterpart. Except for handling bignums in some way or other (perhaps on overflow only).<p>[lwn] <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;691243&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;691243&#x2F;</a>