Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 3 Performance - Not Good Enough

blog.tstmedia.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Rails 3 Performance - Not Good Enough

#51

Post by enko »

moe wrote: post #49
fauigerzigerk wrote: post #17

I think the real problem with Rails and similar frameworks is the culture of not giving a shit about performance. I would never ever release a new version of anything that is significantly slower than the previous one. It's simply a bug in my view. But there are people who have convinced themselves that as long as it scales out, it doesn't matter how many servers you have to run. And if the reason is that something t…

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

Well, this comment just comes across as sour grapes to me. You could be criticising any memory managed programming language. Old timers have been complaining about the kids not knowing about assembly, registers, punch cards, valves, etc since computers were invented.

As for "incompetent design" - I don't know what you are on about. I think that Rails 3 is a frigging triumph of elegant, modular design. There are very many gems in the ruby ecosystem that I believe any unbiased person would say demonstrate exemplary design. In fact, I would say that the average rubyist is much more concerned with good design than, say, your average java dev. The whole reason I switched to ruby was because of the beauty of the language. And what is beauty but good design applied?

Of course there are always exceptions but on the whole I think this comment is quite unfair.

Re: Rails 3 Performance - Not Good Enough

#52

Post by philjackson »

rhizome wrote: post #39
philjackson wrote: post #20

Earlier quoted context omitted.

Wouldn't we all be writing our web apps in C if we never allowed a performance degradation?

Some people do: it's called mod_perl. You can compile a stripped-down Apache (written in C) with mod_perl (also written in C) built in. This basically runs as a C http server that understands Perl, running the script within Apache process space . It's pretty darn close to the metal. The interpreter is the sticky part here and something for which Perl gets some criticism in this arena, but the Perl interpreter is also…

Yea, mod_perl isn't the same thing as writing your application in C, but anyway, my point was in reference to the parents comment:

"I would never ever release a new version of anything that is significantly slower than the previous one. It's simply a bug in my view."

I was trying to get across that we give some up performance for convenience now and again and it's fine to do so. I worked on the BBC iPlayer API which was written on mod_perl, by the way.

Re: Rails 3 Performance - Not Good Enough

#53

Post by aneth »

I've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch cards and wait a whole day, but that's little consolation when node.js starts up in under a second.

There are hacks and fixes to this like spork, but none of this should be necessary. The performance issues are not debated in the open enough. I don't understand how those startup times are acceptable to anyone, but I rarely get responses when I ask questions about it.

http://stackoverflow.com/questions/5738443/why-is-rails-boot...

UPDATE: I have the latest top of the line Macbook Air - 2.13 Ghz Core 2 Duo with SSD.

I have other issues with Rails, but this is the only potential deal breaker. (I tend toward functional clarity instead of "human" readability in the magic debate, while most "Rubyists" would rather pollute the namespace (e.g. metawhere) and create 100 line method_missing calls to make one command slightly prettier aesthetically. And Cucumber - ugh what a ridiculous contraption that is.)

Re: Rails 3 Performance - Not Good Enough

#54

Post by towelrod »

fauigerzigerk wrote: post #44
towelrod wrote: post #38

Earlier quoted context omitted.

The problems here are manifesting on Ruby 1.8.7, but not 1.9.2. There have been big performance problems found with 1.8.7, for example in this issue: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/... What was originally a performance optimization on 1.9.2 caused a terrible slowdown on 1.8.7. It was reported and fixed within two days. Does that still fit into your "not giving a shit about performance" cr…

If the performance degradation is considered a bug, that changes the picture a little bit. But I agree with nirvdrum's comment on using exceptions as control stuctures.

I hear what you are saying about exceptions, but you also have to live in reality. Look at danielparks benchmarks in this thread; rails3 under 1.9.2 is faster than rails2 under 1.8.7.

Its easy enough to spout platitudes like "don't use exceptions for flow control", except remember two basic facts about the commit that I linked:

1. It was using exceptions for flow control as an optimization 2. That optimization was indeed faster on 1.9.2

On top of that, when the rails team was notified about how bad this "optimization" was in 1.8.7, they immediately fixed it.

I just don't see how any of this fits into "don't give a shit about performance".

Re: Rails 3 Performance - Not Good Enough

#55

Post by hyperbovine »

moe wrote: post #49
fauigerzigerk wrote: post #17

I think the real problem with Rails and similar frameworks is the culture of not giving a shit about performance. I would never ever release a new version of anything that is significantly slower than the previous one. It's simply a bug in my view. But there are people who have convinced themselves that as long as it scales out, it doesn't matter how many servers you have to run. And if the reason is that something t…

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

> On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations.

Isn't the entire goal of computer science to abstract away complexity?

Re: Rails 3 Performance - Not Good Enough

#56

Post by towelrod »

nirvdrum wrote: post #41
towelrod wrote: post #38

Earlier quoted context omitted.

The problems here are manifesting on Ruby 1.8.7, but not 1.9.2. There have been big performance problems found with 1.8.7, for example in this issue: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/... What was originally a performance optimization on 1.9.2 caused a terrible slowdown on 1.8.7. It was reported and fixed within two days. Does that still fit into your "not giving a shit about performance" cr…

I think your example might actually support the parent's POV more than it refutes his stance. Exception handling isn't just slow in 1.8.7. It may be slower in 1.8.7 than 1.9.2, but exception handling is universally slow. There are a variety of reasons for this, but unrolling an exception is fundamentally slow and until there's native support for them on the die, that's likely to remain the case. So, creating a situat…

>exception handling is universally slow.

Except that exception handling is so fast in 1.9.2 that it made this change a performance optimization in 1.9.2. Look lower in this topic for benchmarks showing that Rails 3 is faster in 1.9.2 than rails2 is under 1.8.7.

>performance-wise it almost certainly will always be slower

Except, it wasn't slower in the Ruby that most people running Rails 3 should be running (1.9.2).

I also point out, again, that they immediately fixed this problem when someone pointed out how slow it was in 1.8.7.

Re: Rails 3 Performance - Not Good Enough

#57

Post by jpr »

aneth wrote: post #53

I've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch card…

How often do you need to endure that 20-30 second startup time? Is it every time you change anything?

Re: Rails 3 Performance - Not Good Enough

#58

Post by strmpnk »

Interesting, though I no longer use ActiveRecord in my largest app because of how slow it is (even in Rails 2). Try checking the overhead of instantiating (no save or db lookup) a simple model instance with 2 fields for example.

If you manage to avoid that, you've beaten the slowest parts. The view engine is also slow but I tend to do rendering in the browser these days so that barely matters too me.

If you are careful, it is very realistic to have response overhead from rails hover around 1-2ms for simple things and maybe up to 10-20ms for the most complex business logic (expensive validations). It's kind of odd that people who care about performance assume they have to take the whole package as is.

Re: Rails 3 Performance - Not Good Enough

#59

Post by moe »

hyperbovine wrote: post #55
moe wrote: post #49

Earlier quoted context omitted.

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

> On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. Isn't the entire goal of computer science to abstract away complexity?

You can drive a car without knowing how an engine works. But you can't design a [good] car without that knowledge.

Re: Rails 3 Performance - Not Good Enough

#60

Post by fauigerzigerk »

towelrod wrote: post #54
fauigerzigerk wrote: post #44

Earlier quoted context omitted.

If the performance degradation is considered a bug, that changes the picture a little bit. But I agree with nirvdrum's comment on using exceptions as control stuctures.

I hear what you are saying about exceptions, but you also have to live in reality. Look at danielparks benchmarks in this thread; rails3 under 1.9.2 is faster than rails2 under 1.8.7. Its easy enough to spout platitudes like "don't use exceptions for flow control", except remember two basic facts about the commit that I linked: 1. It was using exceptions for flow control as an optimization 2. That optimization was in…

Obviously, I didn't form my opinion on that attitude based on this particular issue. But maybe you're right and the Rails leopard has actually changed its spots. Apart from that, it's unclear whether the slowdown in NGIN is caused by this one line of code alone.
Post reply on HN