1 of 8

Why is Python slow

Kevin Modzelewski kmod@dropbox.com

2 of 8

It’s not what many people think

Getting rid of “interpreter overhead” provides very small wins.

​

Also one of the easiest things for the user to do themselves.

3 of 8

Try it yourself

Compile with Cython without type annotations

  • About 10-20% faster (but with other shortcuts too)

4 of 8

Try it yourself

��

​

4.5 ns/bytecode 9.0 ns/bytecode

sqlalchemy_smalltest2_10x.py: 111 ns/bytecode

​

def f():

a = 1

for i in range(10000000):

a; a; a; a; a; a; a; a

a; a; a; a; a; a; a; a

a; a; a; a; a; a; a; a

f()

def f():

i = 10000000

t = 0

while i:

t += i

i -= 1

f()

5 of 8

What is it then?

​

Lots of expensive features

Dynamic overhead of the runtime

6 of 8

“Speed bumps”

  • Support not calling PyType_Ready
  • Strong signal handling guarantees
  • Tracebacks (including frame info) for every exception
  • sys.exc_info() / 0-arg raise
  • isinstance() override checking
  • Predictable deallocation (prevents fast refcounting schemes)

7 of 8

Dynamic runtime

​

�

The C runtime is 6x slower than an equivalent javascript loop!

import itertools

sum(itertools.repeat(1.0, 100000000))

8 of 8

Conclusion

Lots of time has been invested into interpreter overhead

  • If this was the issue Python would be fast by now

​

Let’s shift the effort to other areas