<story><title>Why Python is Slow: Looking Under the Hood (2014)</title><url>http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/</url></story><parent_chain></parent_chain><comment><author>wruza</author><text>&amp;gt;[boxed values...] The dynamic typing means that there are a lot more steps involved with any operation. This is a primary reason that Python is slow compared to C for operations on numerical data.&lt;p&gt;Not exactly. Setting typecodes and vals doesn’t slow things down by many orders of magnitude. The main reason python is relatively slow is that there is no practical way to reason about what parts of program may be optimized out or leveled down to native datatypes and then restructured in a very efficient way. This is what optimizing&amp;#x2F;jit compilers do to achieve much performance; this one is the source of x100, not unboxing on its own. Technically, tracing jit that doesn’t care if you’re writing in static or dynamic, strict or duck typing can be done for any language, but (afaik) python is not very jit-friendly in general.</text></comment>
<story><title>Why Python is Slow: Looking Under the Hood (2014)</title><url>http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/</url></story><parent_chain></parent_chain><comment><author>hasenj</author><text>Python is optimized for small programs being easy and quick (and pleasant) to write.&lt;p&gt;Every other use case it fails in some way. For being slow. For lacking static typing. For lacking compilation. For having a GIL. etc.</text></comment>