Codename One Boosts Performance with Faster Maps
Codename One improves map structures and expands Tagged Values on ParparVM, dropping missing-key lookup time from 32.7 seconds to 44.9 ms.
Stock photo for illustration only, not from the actual event
- Reduced missing-key map lookup time from 32.7 seconds down to just 44.9 ms.
- Extended Tagged Values support to Short, Character, Float, Long, and Double.
- Lowered boxed allocations in JSON-like workloads from 24.02 to 5.24 per map.
Recent performance optimization efforts by Codename One—an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase—have focused heavily on map operations and memory management on ParparVM, drawing inspiration from Swiss table designs.
Previously, the development team uncovered a severe bottleneck when benchmarking missing keys. Three million containsKey calls took a staggering 32.7 seconds, while benchmarks querying existing keys ran smoothly. Investigation revealed that missing keys triggered linear probing walks through thousands of entries due to suboptimal hash distributions.
Stock photo for illustration only, not from the actual event
To fix this, the team adjusted the probe sequence by adopting CPython's dictionary probing recurrence. They also enhanced string equality checks by caching unequal hashes and routing compatible UTF-16 arrays through native memcmp to leverage platform-optimized vector comparisons. Consequently, the miss-heavy workload execution time dropped dramatically from 32.7 seconds to 44.9 ms.
Beyond map optimizations, the team expanded Tagged Values in ParparVM. While previous versions already avoided separate allocations for Integer.valueOf, PR #5735 extends tagged immediates to Short, Character, Float, Long, and Double by utilizing the three low bits of 64-bit aligned object addresses as type tags.
This encoding strategy allows small primitive values to fit directly within the reference-sized word that would normally point to a separate wrapper object, significantly reducing the pressure on the garbage collector, especially in JSON parsing pipelines.
"An allocation census checks the mechanism independently of elapsed time. The JSON-like workload fell from 24.02 boxed allocations per map to 5.24."
Dev.to
An independent allocation census confirmed these efficiency gains, showing that JSON-like workloads dropped boxed allocations from 24.02 down to 5.24 per map, closely aligning with the coverage rates of the new tagged representation.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment