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

Ruby has a built-in profiler. Fair enough, let's run it, it would be
interesting. You started a new thread, but my comment was part of a
different thread comparing (and disparaging) Ruby against other languages
(and frameworks) typically used for Web development. And my point was that
Ruby itself isn't the problem.

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). 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.
On 7/2/06, Robert Mela <rmela / rcn.com> wrote:
>
> What tools exist for profiling Ruby?
>
> What might answer a lot of these questions is something along the lines
> of a call tree showing time spent ( clock/sys/user) or CPU cycles for
> each node of the tree (node and node+children).
>
> Other questions:
>
> Does a Rails development do more checking and recompiling than a rails
> production environment?  If so, by how much does that affect results?
>
> Is your CGI loading and initializing the Ruby interpreter each time its
> invoked?
>
>
> Francis Cianfrocca wrote:
> >
> >
> > We recently did a simple hello world test with Rails on a very low-end
> > machine and compared it with a Ruby framework that we built for our
> > commercial apps. Both apps had no database, and simply served the phrase
> > "Hello, world" with a text/plain mime type. The test client was running
> > localhost to minimize TCP and network effects. Rails was running in
> > fast-cgi
> > mode (one process for the whole run) and our framework was running in
> CGI
> > mode (one fork per request).
> >
> > Rails did 20 pages per second. The other app did 200 per second.
> > (Straight-run apache with a cached static page of similar size could
> > probably do 1000/second or more on this machine.)
> >
> > Bear in mind, both of these frameworks are *Ruby*. This tells me the
> > comparison to other languages is misleading at best.
> >
>
>
>
>

------art_15336_1322900.1151871099964--