
Warning: RoR is slow - keiretsu

======
tx
How can you so blindly proclaim something like this? In a world of systems
programming I got used to people posting stack traces with milliseconds
attached to each function call, complaining about something _specific_. A good
example would be GNU glibc's printf() function checking system locale on every
call.

Have you ever done any programming before?

Your claim _Active Record is slow_ sounds almost like _my computer is slow_.
How do you know it was ActiveRecord? How did you benchmark? Was it even RoR?
Maybe you had another process spinning in an endless loop in the background
eating your CPU.

~~~
keiretsu
maybe because i've time-profiled it? maybe because i've calculated the time it
took to instantiate a new AR object for every new db record? maybe because the
results show that the AR component took the largest portion of the page
loading time?

~~~
ricardo
Your original post doesn't mention any of this. I think it would help everyone
understand your point a lot better if you posted a few specifics...

------
keiretsu
First of all, i don't wish to try to start a flame war. Just want to share
some of my experience with RoR.

RoR, to me, is the pinnacle of web programming orgasm. It's fun, it's fast,
it's super productive. Hell, i never enjoyed web programming till i tried RoR.

Unfortunately, RoR is slow, or specifically ActiveRecord is slow. No matter
how many machines you throw at your app, there is still a noticeable page
loading time lag compared to a straightforward PHP script. People hate it.
Yes. They do. Users will complain and the only way you can improve the loading
time drastically is if you stop using ActiveRecord. But heck, half of the joy
in using RoR is with ActiveRecord. Either that or you cache page fragments.
But trust me, caching page fragments is not fun. You need to keep track of
which fragments to invalidate based on which model actions. Multiply that with
many models and you get the same PHP messiness.

So what's my point? My point is that i'm looking for a new FAST mini-framework
to replace RoR. Any recommendations :)?

~~~
bjclark
What name are you submitting patches for AR under (I'm not finding any under
your username here,
[http://dev.rubyonrails.org/search?q=keiretsu&wiki;=on&changeset;=on&ticket;=on)](http://dev.rubyonrails.org/search?q=keiretsu&wiki=on&changeset=on&ticket=on\))
? I'd like to check some of them out to see what your doing. I'm assuming your
not just complaining about a free open source project and that your actually
doing something about it, since just complaining is pretty bad for your karma.

~~~
aston
It's no longer okay to complain? If I didn't like something, I'd prefer to
complain and not use it than waste my time fixing something I find
fundamentally flawed.

~~~
bjclark
No, It's not ok to just go around complaining. If you don't like it, that's
fine, don't use it, but to just go around posting completely unproven slander
about a completely free project is another matter completely.

I love that there are some people here that seem to think they are entitled to
something or that 37s or DHH owes you something. It's open source, you have 3
options: 1\. Fix it and get kudos. 2\. Don't fix it (because your either too
dumb or too lazy) and work around it. 3\. Don't use it.

But coming on here and making some generalized proclamation that RoR is slow
is irresponsible and unacceptable, IMO.

------
AF
Unless you've really got a Ruby fetish, there's just not much of a reason to
use it.

If you want a similar language with similar productivity, Python gives you
that and speed, Unicode support at the language level, and lots of libraries.

And in web frameworks alone you've got Django, Pylons, Turbogears, web.py,
etc. Django has the community and 'push' that Rails does in the Ruby world,
and Pylons feels a lot like Rails. So what are you waiting for? Checking them
out can't hurt anything.

~~~
jamesbritt
I tried Python; didn't care for it. Something just didn't click.

Later on I tried Ruby, and it was a better fit for my head.

There are differences in the underlying design principles of Ruby and Python,
and they can make a big difference in how well you internalize the language.

I also took a look at Django, and it struck me as astonishingly clunky
compared to Rails and Nitro.

There are issues of aesthetics at play; I can't argue that my taste is right
or wrong, but it certainly matters that I use a tool that aligns with it.

~~~
keiretsu
yeah. i agree. tried python. the language is really _ugly_ compared to ruby.
django just doesn't fit into my brain like RoR does.

~~~
far33d
I think that once you get past the whitespace dependence, python is an
incredibly elegant language. No strange variable prefixes, functions as
primary data, readable syntax, etc etc. And, if you come from the land of
C/Java/C++, it has quicker transition than ruby (IMHO)

------
richcollins
Hrm most of the posts here show little understanding of Rails. Rendering, not
AR is behind most complaints of "slowness". If you want to speed up rendering,
limit the amount of redundant Javascript that gets generated, statically
generate links, don't generate SQL (eager load) and cache where needed.

~~~
asdf333
No. As someone who runs a site w/ more than half a million hits a day at
times, rails is butt slow. We memcache up the wazoo as well as make other
optimizations.

Not only is it slow but there are memory leaks too.

I hope they fix alot of this. We went w/ rails b/c of the elegance, but paid
for being on the bleeding edge.

~~~
sbraford
Can you share the URL of your site?

Just curious - what are your plans going forward?

i.e. continue what you've been doing, rewrite in another language, or what?

Not that this is your scenario, but whenever I'm in a crunch situation, it
always feels like the grass is always greener. When you get to the other
side... well, you know how it goes.

~~~
asdf333
Unfortunately I can't b/c of some reasons I'd be happy to share later. I know
it sounds like a copout, but really, I'd be in trouble if I mentioned it now.

Upper mgmt is making us rewrite it in java. (shoot self). It has more to do
with what they are comfortable with long term and what the company runs and
has the know-how to support.

If I had to do it over again, I'd look at Python more carefully. Django was
barely out when we started so we were a bit leery of it. In addition, I didn't
have a great impression of Python from doing some toy programs in it. I really
liked Ruby's elegance.

Overall, I don't think we would've chosen Java above what we have, warts and
all. Java is too verbose and RoR let us be extremely flexible and fast when it
mattered.

Outside of upper management intervention, we'd probably have continued down
the ruby path and gambled on the fact that things would be fixed/better in a
few years.

I feel for twitter, but they're really doing a service for the rest of the RoR
community by being the pioneer for extreme scaling issues.

------
dcancel
I've moved to Django, huge performance difference. Also a simpler stack,
apache + mod_python vs the nginx + mongrel or apache/lighttpd + fcgi or
etc....

------
count0
To be fair, the current implement of Ruby (1.8x) is slow because it does not
compile source code to byte code and run in vm, which will be available in
next version (2.0?). Python, on other hand, already use this for a long time.

So, just stick to it and wait if you like the beauty keyword "end" and dislike
white space vs tab war.

------
jmcantrell
Ruby and RoR, slow? This is a no-brainer. Ruby is slow as molasses and RoR is
built upon Ruby. Hmmmmm....

~~~
jamongkad
The implementation of JRuby should fix this concern.

------
russ
Something to look into: I don't know if any of you guys went to RailsConf, but
one of the goals of Rails 2.0 is to improve AR through the caching of repeated
queries at the AR object level.

~~~
keiretsu
I've already done this. Got a minor speed bump. You have to understand that
the majority of the page loading time is in the instantiation of the AR
object, not from fetching the db result. At least that's my experience in my
app.

------
sabat
There are a lot of valuable comments here.

If I had to summarize what I think is the likely problem, I would say: look
into pre-fetching where it makes sense. Databases are often troublesome
beasts, and you have to do more management of the data than you would like.

