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

------=_Part_16814_22531571.1151890312245
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:
>
> ....could be
> either some fundamental constraint of the langauge semantics (which I
> doubt) or an optimization opportunity in the run-time to deal more
> efficiently with the semantics of the language.

If the opportunity is there, why hasn't someone seen it yet? I'll take even
incremental improvements, but it seems unlikely that something really major
has been missed.



Ah ... now searching is something we *can* optimize!

Searching can be improved but even so, it's a lot of work to do at runtime.
Languages that treat method dispatch as lookups into indexed tables have a
big edge. Even Python does this.



If the Sun JVM
> can do it, a Ruby interpreter should be able to do it as well.

No knock against Sun's engineers, some of the sharpest folks in the
business. But that poster was referring to the Solaris/Sparc JVM, which in
my experience is perhaps the least well-executed JVM around. Ugh. There's a
limit to the amount of server RAM I'm willing to buy, power, and cool just
to run bloatware.



I'm not sure what you mean here, both in terms of "objects in
> automatically-distributed containers" and "productivity-upside". Are you
> looking for something like "lightweight processes/threads" or what is
> known as "tasks" in classic FORTH?

Nothing like that. I'm trying to make my life easier, not harder ;-). The
main reason I'm attracted to Ruby is the promise of developing a lot more of
the unbelievably large amount of code that has to get written while reducing
the critical dependency on high-quality personnel, which is a
highly-constrained resource in uncertain supply. (I'm eliding some of my
thinking here of course, so you may well challenge that statement.)
I'd like to run plain-old Ruby objects in container processes that know how
to distribute loads adapatively and keep individual process sizes small, and
interoperate with objects written in other languages. In general I work with
applications that require extremely high throughputs but can tolerate
relatively large latencies (milliseconds as opposed to microseconds) as long
as all the system resources are fully utilized. I want to take advantage of
the coming multiprocessor hardware, but I don't want to do it with
multithreading (life's too short for that).

>>>The application area is matrix calculation for the most part,
That sounds like the kind of thing I would use Ruby only to prototype. But
you've been around the block a few times, so who am I to say? ;-)

------=_Part_16814_22531571.1151890312245--