here - Stefan-Marr.de

8. Evaluation: Performance
1.4
1.3
1.2
1.1
1.0
Binary Trees
Chameneos
Fannkuch
Fasta
NBody
Compiler
Slopstone
Smopstone
Runtime Ratio, normalized to RoarVM (opt)
lower is better
RoarVM+OMOP (opt)
RoarVM (opt)
Figure 8.7.: Inherent Overhead: Comparing RoarVM (opt) with RoarVM+OMOP
(opt) to assess the inherent overhead of OMOP support on the execution performance.
The benchmarks do not utilize the OMOP, and thus, they expose that
changes to the interpreter cause an average overhead of 17% on interpretation.
formance impact of the memory overhead has not been measured, but it is
likely that the overhead significantly depends on average object size, and has
an impact on GC times.
RoarVM+OMOP For the RoarVM implementation of the OMOP, the situation
is different. While it also suffers from memory overhead per object for
the additional object header that represents the owner (cf. Sec. 7.2.1), it also introduces
changes that have a direct effect on the execution performance. The
code path for unenforced execution through the interpreter now contains additional
checks, which have an inherent impact on overall performance, also
for unenforced execution.
Fig. 8.7 23 shows that the overhead ranges from minimal 7% up to 31%. The
average runtime overhead of the OMOP support is about 17%. The overhead
is explained by the additional code on the fast path of the code. All bytecodes
that perform operations relevant for the OMOP apply an additional test to the
interpreter object which checks whether execution is performed with enforce-
23 The beanplot library of R forced a linear scale for this graph.
222