Python Interpreter Performance Deconstructed

ABSTRACT

The Python programming language is known for performing poorly on many tasks. While to some extent this is to be expected from a dynamic language, it is not clear how much each dynamic feature contributes to the costs of interpreting Python. In this study we attempt to quantify the costs of language features such as dynamic typing, reference counting for memory management, boxing of numbers, and late binding of function calls.

We use an experimental compilation framework for Python that can make use of type annotations provided by the user to specialize the program as well as elide unnecessary reference counting operations and function lookups. The compiled programs run within the Python interpreter and use its internal API to implement language semantics. By separately enabling and disabling compiler optimizations, we can thus measure how much each language feature contributes to total execution time in the interpreter.

We find that a boxed representation of numbers as heap objects is the single most costly language feature on numeric codes, accounting for up to 43% of total execution time in our benchmark set. On symbolic object-oriented code, late binding of function and method calls costs up to 30%. Redundant reference counting, dynamic type checks, and Python's elaborate function calling convention have comparatively smaller costs.

References

1. {Bar13} Gergö Barany. Static and dynamic method unboxing for Python. In 6. Arbeitstagung Programmiersprachen (ATPS 2013), number 215 in Lecture Notes in Informatics, 2013.
2. {Bar14} Gergö Barany. pylibjit: A JIT compiler library for Python. In Software Engineering 2014 (Workshops), number 1129 in CEUR Workshop Proceedings, 2014.
3. {BCFR09} Carl Friedrich Bolz, Antonio Cuni, Maciej Fijalkowski, and Armin Rigo. Tracing the meta-level: PyPy's tracing JIT compiler. In Proceedings of the 4th workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages and Programming Systems, ICOOOLPS '09, pages 18--25, New York, NY, USA, 2009. ACM.
4. {Bru10a} Stefan Brunthaler. Efficient interpretation using quickening. In Proceedings of the 6th symposium on Dynamic languages, DLS '10, pages 1--14, New York, NY, USA, 2010. ACM.
5. {Bru10b} Stefan Brunthaler. Inline caching meets quickening. In Proceedings of the 24th European conference on Object-oriented programming, ECOOP'10, pages 429--451. Springer, 2010.
6. {Bru13} Stefan Brunthaler. Speculative staging for interpreter optimization. CoRR, http://arxiv.org/abs/1310.2300, 2013.
7. {HH09} Alex Holkner and James Harland. Evaluating the dynamic behaviour of Python applications. In Bernard Mans, editor, ACSC, volume 91 of CRPIT, pages 17--25. Australian Computer Society, 2009.
8. {MG11} Jason McCandless and David Gregg. Optimizing interpreters by tuning opcode orderings on virtual machines for modern architectures: Or: How I learned to stop worrying and love hill climbing. In Proceedings of the 9th International Conference on Principles and Practice of Programming in Java, PPPJ '11, pages 161--170. ACM, 2011.
9. {MKC+10} Nagy Mostafa, Chandra Krintz, Calin Cascaval, David Edelsohn, Priya Nagpurkar, and Peng Wu. Understanding the potential of interpreter-based optimizations for Python. Technical Report 2010-14, UCSB, 2010.
10. {num} numba: NumPy aware dynamic Python compiler using LLVM. https://github.com/numba/numba.
11. {PR13} Russell Power and Alex Rubinsteyn. How fast can we make interpreted Python? CoRR, http://arxiv.org/abs/1306.6047, 2013.
12. {Sel09} Dag Sverre Seljebotn. Fast numerical computations with Cython. In Proceedings of the 8th Python in Science conference (SciPy 2009), 2009.
13. {VSB} Michael M. Vitousek, Jeremy G. Siek, and Jim Baker. Design and evaluation of gradual typing for Python. http://wphomes.soic.indiana.edu/jsiek/files/2014/03/retic-python.pdf. {Online draft; accessed April 4, 2014}.

Index Terms

• Software and its engineering

  • Software notations and tools

    • Compilers

      • Interpreters