This doesn't add up for me. Unless they've been working on this for a long time - at least a year, why did they pick the very slowest current version of Ruby to start this process with?
Ruby 1.9 gives you an easy doubling of performance from base Ruby 1.8. Ruby Enterprise Edition is a worthy upgrade to the 1.8 codebase, but 1.9 is where the action should be. I haven't used 1.8 for over year, 1.9 is that good.
For some reason they mention maybe trying Ruby 1.9 and JRuby at some future time.
If you care about performance, and you want to play with heap implementations, then the JVM has you covered. JRuby is the version I would have started with just to play with GC settings.
I'm all for playing with stuff to find things out, but this feels like they aren't spending their time wisely to get the result that they need.
3 comments
[ 3.3 ms ] story [ 15.7 ms ] threadRuby 1.9 gives you an easy doubling of performance from base Ruby 1.8. Ruby Enterprise Edition is a worthy upgrade to the 1.8 codebase, but 1.9 is where the action should be. I haven't used 1.8 for over year, 1.9 is that good.
For some reason they mention maybe trying Ruby 1.9 and JRuby at some future time.
If you care about performance, and you want to play with heap implementations, then the JVM has you covered. JRuby is the version I would have started with just to play with GC settings.
I'm all for playing with stuff to find things out, but this feels like they aren't spending their time wisely to get the result that they need.
I agree with you however. 1.9 is the future and that's where they should be spending their time. Let 1.8 die already...