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::sort
method with default comparator. - Java block comparator: passing a block comparator to the Java
Collections::sort
method using the closure conversion interface implementation ofjava.util.Comparator
. - Java class comparator: passing a class comparator to the Java
Collections::sort
method 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::sort
on string collection using the default comparator yield similar performance. - (4 & 5) Curiously using Java
Collections::sort
on 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::sort
using a class comparator on comparable objects has similar performance.