blog/beating-hotspot-performance/

[giscus[bot]]

blog/beating-hotspot-performance/

ParparVM went from 4.21x slower than warmed Java 25 to geomean parity, with six of ten benchmarks at or below HotSpot and peak memory below the JVM's. The architecture behind it: frameless C codegen, a BiBOP page heap, and a poor man's Valhalla.

https://www.codenameone.com/blog/beating-hotspot-performance/

[ddyer0]

I'm one of the customers who "occasionally complained" about ParpaVM performance. My standard CPU-oriented benchmark, not very scientific
but suitable to my use case (game tree search), rated IOS code at 0.05 standard CPUs. Today, I noticed that my build got significantly larger,
and was pointed to this blog entry. Today, IOS code is rated at 0.5 standard CPUs. 10x is not bad for an untuned blind test!

[shai-almog]

10x indicates that your code probably did a lot of short term allocations which were a weak spot in our VM implementation.

[ddyer0]

At 09:39 AM 7/14/2026, Shai Almog wrote:

10x indicates that your code probably did a lot of short term allocations which were a weak spot in our VM implementation.

My test is intended as a recursion/function calling test, but from your blog I would guess the integer boxing improvements is dominant. I'll run a more realistic test later today. Performance is a complex topic.