------art_1410_26850645.1190910242970
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/27/07, Roger Pack <rogerpack2005 / gmail.com> wrote:
>
> Thanks Kirk.
>
> Follow-up question: it seems like there have been a lot of 'replacement
> attempts' of the Ruby interpreter, but none of them seem to have really
> really sped it up (jruby, rubinius, etc.) They do add cool features like
> thread safeness or what not, and in certain instances are faster, but
> not like 'we've overcome the bottleneck!' faster.
> Does this mean that they suffer from the same bottlenecks?  Is Ruby just
> a hard language to optimize for?  Do they all tree walk and have slow
> method dispatch and a slow GC or something?  Hmm.
>
> Stay well.
> -Roger
> >> So my question is...where is the bottleneck?  Is it in method lookup?
> > The dynamic nature of the method dispatch.  The overall implementation
> > --
> > both the tree walker versus a vm, and some of the implementation
> > details.
> > The GC can also be a bottle neck.  It stops the world when it runs, and
> > it
> > has to touch every object when it runs, so as the program gets bigger
> > (in
> > object count), the GC burden gets higher.
> >
> --
> Posted via http://www.ruby-forum.com/.
>
>


I agree with Kirk. Ruby's inherent performance bottleneck is also its most
distinctive feature: the open classes and data structures. There's always
going to be a limit to how much faster you can do name-resolution at
runtime, since it's costly to begin with, and you can't deterministically
predict it. (There are approaches to adaptively predict name-bindings at
runtime, notably from Smalltalk, and I expect JRuby will be able to leverage
them. But they can ameliorate, not solve, the fundamental issue.)

Garbage collection and poor memory usage, on the other hand, are problems
that can and should be solved.

I used to believe that large Ruby programs could be constructed as
independent coarse-grained modules running in their own processes,
communicating through message-passing. Having done quite a bit of this now,
I think the approach helps quite a bit, but still suffers from memory usage.
It's hard to get the memory-usage of even a small Ruby program down to a
level that would permit (perhaps) hundreds of cooperative processes to be
running at once.

Bottom line: using Ruby will always be characterized by a tradeoff between
performance and programmer productivity. This is not a criticism of Ruby in
any way, shape or form! Productivity is a fundamental engineering value, and
time-to-market is a fundamental quality dimension. Ruby therefore has, and
will continue to have, a unique value proposition.

------art_1410_26850645.1190910242970--