From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-07-03T08:53:35+09:00
Subject: Re: Ruby and Rails performance profiling?

------=_Part_16193_27461839.1151884412350
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/2/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>
> I personally don't think it a "necessary consequence of Ruby's extremely
> dynamic nature." There are a couple of things it could be:
>
> 1. Page faulting with large working sets. There are things you can do to
> the interpreter to enhance locality and minimize page faulting, but if
> you have two 256 MB working sets in a 256 MB real memory, something's
> gotta give.
>
> 2. Some process in the run-time environment that grows faster than N log
> N, where N is the number of bytes in the working set. Again, putting on
> my statistician's hat, you want the interpreter to exhibit N log N or
> better behavior on the average.


 Ok, but these are problems that affect any program regardless of what it's
written in. If that's your theory, then you still need to explain why Ruby
in particular seems to be so slow ;-).

I could figure this out if I were frisky enough (but someone probably
already knows), but it seems like Ruby takes a Smalltalk-like approach to
method-dispatch. Meaning, it searches for the method to send a message to,
on behalf of each object. Whereas a language like Java views method-dispatch
as calling a function pointer in a dispatch table that is associated with
each class, and can easily be optimized. That's what I meant by Ruby's
"extremely dynamic nature." And the fact that classes and even objects are
totally open throughout runtime makes it all the more challenging. As a
former language designer, I have a hard time imagining how you would
automatically optimize such fluid data structures at runtime. You mentioned
page faulting, but it's even more important (especially on multiprocessors)
not to miss L1 or L2 caches or mispredict branches either. If you're writing
C++, you have control over this, but not in Ruby.

The more I work with Ruby, the more I find myself metaprogramming almost
everything I do. This seems to put such a burden on Ruby's runtime that I'm
looking for simpler and more automatic ways to run Ruby objects in
automatically-distributed containers, to minimize the working sets. The
problem is worth solving because the productivity-upside is just so
attractive.

------=_Part_16193_27461839.1151884412350--