DiffJ is nearly ready for release, but I’ve not been content with the performance, which is significantly slower with the JRuby implementation than the pure Java version.
My changes were based on the recommendations on the JRuby wiki.
Before any optimization, a test run of diffj against a pair of Java files ran with the times:
user : 4.84 system : 0.19 cpu : 184.20 total : 2.72
Following the suggested changes, I added the -client argument to the Java process, which resulted in:
user : 4.99 system : 0.21 cpu : 184.80 total : 2.80
So performance actually worsened.
Next was passing the argument -Djruby.compile.mode=OFF arguments to the Java process:
user : 4.92 system : 0.17 cpu : 184.80 total : 2.75
Again, performance worsened slightly.
With both the -client and -Djruby.compile.mode=OFF arguments, performance was still down, as one would expect now:
user : 4.92 system : 0.18 cpu : 186.00 total : 2.73
So then I more carefully went through my code, looking at the time to require each file, and found two salient problems.
The first is that I was dynamically creating several hundred methods in the RIEL ANSIColor class, for each combination of decorations and foreground and background colors (such as “bold_red_on_white”). I refined that code, the RIEL Log and Loggable classes, and the extensions to the Ruby String class to dynamically create the color methods as necessary.
Thus the dynamic definition of the method “bold” is truly a usage of the decorator pattern.
That resulted in a slight improvement:
user : 4.68 system : 0.22 cpu : 186.80 total : 2.62
I wondered about the overhead of Rubygems, so I removed RIEL as a gem, and instead added it within the DiffJ source tree. Performance improved significantly:
user : 3.74 system : 0.20 cpu : 184.80 total : 2.13
Combining all of the above resulted in the best performance:
user : 3.62 system : 0.19 cpu : 181.20 total : 2.10
That is acceptable to me, and I’ll be releasing version 1.3.0 of DiffJ soon. Of course, it’s on Github here, so feel free to download it and build it.