REE does a great job reducing memory allocations, and therefore CPU usage. But to get the full effect, you need to do some work yourself, like using a wrapper script to set the tunable GC parameters. And it's not the standard, so you do need to be more careful with it, if you use it, I recommend hanging at least a few weeks behind each release, just in case. I've been using it in production for over a year, and it's definitely better (and easier) than trying to maintain your own patched Ruby interpreter.
The bigger question is: do you have a problem with CPU usage or memory allocation? If you do, then definitely go with REE, you'll see real improvements. If you don't, then avoid the extra complexity. On Jan 4, 2010, at 8:06 AM, Matt Aimonetti wrote: > REE is more efficient than standard's MRI mainly because of some specific > patches like the copy on write (COW) GC patch and a few other ones. The > Phusion guys did a good talk at Google explaining what they did, you might > want to check: > > http://www.youtube.com/watch?v=ghLCtCwAKqQ > > - Matt > > > On Mon, Jan 4, 2010 at 10:59 AM, Jason King <[email protected]> wrote: > To be honest, most of the REE hype is about performance improvements, > and you get 95% of those improvements yourself by just compiling ruby > from source instead of using a distro package. Use whichever takes > your fancy. > > On Jan 4, 2010, at 12:46 AM, Unnsse Khan wrote: > > > Does anyone know how REE < http://www.rubyenterpriseedition.com/ > > > compares with Matz Ruby? Is this the one to be using? > > > > -Unnsse > > > > -- > > SD Ruby mailing list > > [email protected] > > http://groups.google.com/group/sdruby > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
