Summarized benchmark results of different Java interface implementation strategies using JRuby.
The idea is to see the performance impact of using a custom java.util.Comparator interface implemented in JRuby compared to the default native sort in Ruby and Java. The Ruby sort! method and the Java Collections::sort method are tested on both strings and comparable objects collections.
- Ruby default comparator: using the
sort!method with default comparator. - Ruby block comparator: passing a block comparator to the
sort!method. - Java default comparator: using the Java
Collections::sortmethod with default comparator. - Java block comparator: passing a block comparator to the Java
Collections::sortmethod using the closure conversion interface implementation ofjava.util.Comparator. - Java class comparator: passing a class comparator to the Java
Collections::sortmethod using the module mixin interface implementation ofjava.util.Comparator.
| Comparator | Strings | Objects --- | --- | --- | --- 1 | Ruby default comparator | 7.85s | 16.31s 2 | Ruby block comparator | 17.05s | 27.61s 3 | Java default comparator | 7.93s | N/A(1) 4 | Java block comparator | 51.43s | 31.81s 5 | Java class comparator | 40.11s | 18.87s
Notes:
- Java cannot sort non-primitive JRuby objects without a custom comparator
- (1 & 3) As expected both Ruby
sort!and JavaCollections::sorton string collection using the default comparator yield similar performance. - (4 & 5) Curiously using Java
Collections::sorton a collection of comparable Ruby objects is significantly faster than on Ruby strings. - (4 & 5) Using the module mixin interface implementation for a class comparator is significantly faster than using closure conversion interface implementation for the block comparator.
- (1 & 5) Very interesting: both Ruby
sort!using default comparator on comparable objects and JavaCollections::sortusing a class comparator on comparable objects has similar performance.