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 <tom.enebo / gmail.com> wrote: > On Fri, Jan 28, 2011 at 8:59 AM, Kirk Haines <wyhaines / gmail.com> wrote: >> On Thu, Jan 27, 2011 at 1:10 PM, klochner <klochner / gmail.com> wrote: >> >>> Ignoring the between-test comparisons, there is clearly a slowdown >>> after loading rails. ¨ֲ×חץוףףיף פטבפ יפ טבפן הן קיפט פטףיתו ןז >>> 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. ¨ֲטוחבעגבחדןללודפיןמ דשדל>> 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. ¨ֲטילו לןפף > of garbage will have an effect on any GC, some GC's just do a better > job. ¨ֲׂץגש ֳַ פיםובעחומועבללףםבללונועדומפבחו ןז ורודץפין> than the amount of time MRI spends collecting. ¨ֲׂץגש בלףן בללןקף > parallel and concurrent collection (JVM allows a variety of plugable > GCs) which reduces GC pauses by pushing collection onto separate > processor cores. ¨ֲצוקיפטןץץףימפטנבעבללול ןע דןמדץעעומפ > 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