David Masover
8/24/2008 1:51:00 AM
On Saturday 23 August 2008 14:34:34 Roger Pack wrote:
> Question/project wish list:
> Project to improve rails' speed--perhaps by turning certain bottlenecks
> into C or what not.
No, that would actually backfire in a big way, I think. Rails being in Ruby
means that it's portable. It means that when there's a competing, faster VM,
we can run Rails on it and enjoy a speed boost.
Rewriting parts in C would make those parts not portable -- very possibly even
between versions of the mainline Ruby interpreter (many 1.8 extensions don't
work on 1.9).
An example: Rails will now run on more than one webserver -- many people run
it on Mongrel, for example, instead of Webrick. But I seem to remember
Mongrel not working at all on 1.9, last I tried -- it is, after all, quite a
lot of C.
That's OK, because the webserver isn't actually part of Rails, and there are
webservers that work on 1.9.
> A project to optimize the mysql adapter and make it more rails efficient
Well, you could make it more efficient in general, but Rails doesn't tend to
make it easy on the database. (Simple example: Rails never uses prepared
statements. The conditions look like they do, but Rails actually does string
interpolation of your placeholders (those ? chars) in Ruby, and then sends
the whole ginormous SQL query to the database backend, whatever it is.)
I think, if Ruby's being too slow for you, you might start looking beyond
Rails. If it's really the database performance, you could start by replacing
ActiveRecord with a faster, lighter ORM. But actually profile and see if it's
being slow, first -- as they say, premature optimization is the root of all
evil.