Francis Cianfrocca wrote:
> My experience suggests that Ruby's performance "problems" are negligible
> with small working sets and are very serious with large ones (program
> size
> and number of code points seem to matter relatively little). My
> hypothesis
> (no proof adduced) is that this is a necessary consequence of Ruby's
> extremely dynamic nature and is only somewhat amenable to improvements
> like
> YARV and automatic optimizations (as the many Java-like VM proponents
> suggest).
Interesting ... maybe we shouldn't be profiling Ruby code with the
*Ruby* profiler, but profiling the Ruby *interpreter* with "gprof" or
"oprofile". I had assumed that had already been done, though. :)

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.


> So in my own work I tend to design small Ruby processes performing
> carefully-circumscribed tasks and knitting them together with a
> message-passing framework. I think you can make Ruby perform just as
> fast as
> anything else but a style change is required.
>
> And of course the point of the effort is to get Ruby's productivity
> improvements without losing too much at the other end. Time-to-market
> is a
> measurable quality dimension too.
I think this is good advice regardless of the language or the
application. Still, that does pass some of the burden on to the
interpreter and OS, and it doesn't mean we shouldn't use your large
working set codes as test cases to make the Ruby run-time better. :)

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com