6. Performance¶
The Very Slow Jython Project is not directly a search for high performance. The main question is whether an interpreter can be built correctly at all, using the patterns we are exploring. We have mostly avoided “speed-up tricks” in favour of clarity and generality, so we could explore more territory.
However, the reason we explore the territory is that we think (thought) we might find within it an implementation of Python that people will use. For this, it has to be acceptably fast. In fact, the strategic direction (as opposed to tactical choices in any piece of code) has been towards architecture that obtains high performance through proper use of the dynamic language features of Java. These features were not available to the original architects of Jython.
This question of whether we are using these features to best effect, will be reflected in the execution time of individual operations. Both the Python byte code interpreter and Python compiled for the JVM will string together the code for individual operations. Micro-benchmarking is therefore the chosen approach. The operations are:
This chapter collects together some micro-benchmarks on basic operations
in the different implementations being explored, in Jython 2.7.2,
and in the nearest equivalent Java (i.e. with known types) for comparison.
The code is in dedicated sub-projects rt2bm
, dy2bm
, jy2bm
,
rt3bm
and dy3bm
.
All the benchmarks are generated by JMH.
The measurements on VSJ 2 and VSJ 3 are firstly of the abstract API
that supports the Python byte code interpreter.
If there were a compiler for VSJ 2,
its first incarnation would probably emit calls to these methods.
Secondly we consider what might be available through the use of
invokedynamic
call sites,
which is what a full-fledged compiler would emit.
For those interested,
the test CPU is a lightly loaded AMD Athlon II X4 635 at 2.9GHz.
Java identifies as
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)
.