On 9/1/06, Dido Sevilla <dido.sevilla / gmail.com> wrote:
> http://www.joelonsoftware.com/items/2006/09/01.html
>
> Actually, despite the fact that I love Ruby a lot, I'm inclined to
> partially agree with him on this. Presently, our company does have
> some Rails-based web applications deployed but they're predominantly
> applications geared for use by only a few people (internal client use
> only); we've not yet tried to deploy a real public-facing web
> application based on Rails. For that, it works really well.

If anything, your hitherto positive expeirence should cast an
optimistic outlook for Rails' performance in a wider-audience
application.

> high load applications; my own experiences attempting to optimize
> plain Ruby code for performance have been simultaneously frustrating
> and rewarding. I doubt I could do the same with a Rails app.

Rails performacne optimization is very different from Ruby
optimization. There's only so much you can to optimize Ruby for simple
operations. Web applications, however, are usually complex. Solving or
even merely identifying bottlenecks involves making and testing broad
changes rapidly. And that's where Ruby/Rails really shines.

There are many significant optimizations I was able to discover and
implement in Rails, that I simply wouldn't be able to do in PHP
because of its less modular and malleable nature. In fact, I think
VHLLs like Ruby (in conjuction with appropriate frameworks like Rails)
have a solid advantage there over lower level languages, and this edge
will only increase in the future.

> So for
> now we're gonna stick with PHP for our public facing web applications,
> even if it is even worse for i18n/l10n/m17n applications than Ruby
> is...

The first steps I took in Rails were rewriting existing PHP
applications with it. So I have a certain estimate about how the Rails
compares to PHP for very similar applications. Keep in mind those
initial translations were completely naive; I didn't know Rails at the
time, and I didn't do anything like the optimizations mentioned above.

Generally, those naive applications weren't significantly slower than
their PHP equivalents (which themselves were old, tested, optimized
code). At most, the PHP was twice as fast (would handle twice the
requests over the same time period). And that's a maximum estimate -
generally, any difference was hardly noticeable.

In my experience a lot of production PHP applications can be optimized
to at least 2-3 times of their existing performance (and that's
assuming there wasn't really sloppy programming going on, in which
case the gain might easily be many times more). So I don't see why
Rails is any less viable than PHP in that regard. In fact, quite the
contrary: Rails applications I worked on frequently ended up getting
some refactoring after going production, and becoming 2-3 times more
efficient. Refactoring a working PHP application, however, is commonly
such a PITA, I was happy to close the hood after the engine was
running and not bother opening it again unless in the unfortunate
event of a bug.

Regards,
-Alder