From: Thomas E Enebo Date: 2011-01-29T02:17:56+09:00 Subject: Re: performance question Sorry Kirk you were probably specifically talking about Ruby impls based on MRI 1.8.x derived codebases and not in the more general sense. My info may still be interesting to someone, but it was specifically about JRuby and how it can handle GC'ing workloads. -Tom On Fri, Jan 28, 2011 at 11:10 AM, Thomas E Enebo wrote: > On Fri, Jan 28, 2011 at 8:59 AM, Kirk Haines wrote: >> On Thu, Jan 27, 2011 at 1:10 PM, klochner wrote: >> >>> Ignoring the between-test comparisons, there is clearly a slowdown >>> after loading rails.  My *guess* is that it has to do with the size of >>> ObjectSpace causing a slowdown in function lookup, but again, I was >>> hoping someone here would have a more concrete understanding. >> >> Garbage collection. >> >> REE has some optimizations to how it manages GC, but the fundamentals >> are still the same for any 1.8.x.  When a garbage collection cycle >> starts, everything else stops. While it is running Ruby has to walk >> through it's heaps, examining everything that looks like an object >> that it can find. >> >> The more stuff that is in there, the longer this takes. If there is a >> lot of stuff in there, the impact can be significant. > > I totally agree with you Kirk...but... > > I just want to add that not all Ruby GC impls are equal.  While lots > of garbage will have an effect on any GC, some GC's just do a better > job.  JRuby GC times are generally a smaller percentage of execution > than the amount of time MRI spends collecting.  JRuby also allows > parallel and concurrent collection (JVM allows a variety of plugable > GCs) which reduces GC pauses by pushing collection onto separate > processor cores.  Even without using the parallel or concurrent > collectors the percentage pauses are much shorter mostly due to > generational collection. > > -Tom > > -- > blog: http://blog.enebo.com       twitter: tom_enebo > mail: tom.enebo@gmail.com > -- blog: http://blog.enebo.com       twitter: tom_enebo mail: tom.enebo@gmail.com