Why is Python slow?

Python users often complain that the language is slow. Kevin Modzelewski presented some of his findings on Python's slowness at the 2016 Python Language Summit. He works at Dropbox on the Pyston just-in-time (JIT) compiled version of Python; that project has learned some interesting things along the way about what causes Python to be slow.

The question really is why Python is slower than JavaScript, Modzelewski said, it's "obvious why it is slower than C". The common wisdom is that interpreters are slow, but the interpreter overhead for Python isn't that large. Users can get rid of that overhead using different techniques, but still complain that Python is slow.

For example, if you take a Python program and compile it with Cython without any type annotations, you will see around a 10-20% performance increase. You can also try micro-benchmarks to test the interpreter overhead, but those will also suggest that the overhead is not that high.

He asked: "What is it then?" Python has lots of features and some of them are quite slow. The C runtime is "very dynamic", which makes it slow. There are various "speed bumps" that are useful for users, but cost a lot for a JIT compiler. For example, tracebacks that include frame information for every exception are expensive. It is an attractive part of Python, but it has to be turned on all of the time. It might be a decent tradeoff to allow it to be disabled some of the time. "Everyone here can think of more" of these speed bumps, he said.

Another example he gave demonstrates the slowness of the C runtime:

    import itertools
    sum(itertools.repeat(1.0, 100000000))

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.

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.

Modzelewski said that the Python core developers have spent a lot of time on increasing the speed of the interpreter and on optimizing bytecode dispatch in particular. Either those problems have been fixed or those areas weren't really the problem, because enough time has been spent to have fixed problems like that by now. He suggested that efforts to improve Python's performance be shifted to other areas.

Raymond Hettinger wondered about the tradeoffs involved. There is a lot of checking for things like signals and recursion depth in the C runtime that have a fairly high cost. Would it make sense to allow those to be relaxed or eliminated under some circumstances? Modzelewski agreed that it might make sense to try that, but since Pyston is an alternative Python, it can't make those kinds of changes unilaterally. Hettinger was also concerned that there are proposals for features that could make the C runtime costs higher and wanted to ensure that the impact of those was discussed before they become part of the language.

Index entries for this article
Conference	Python Language Summit/2016

---

to post comments