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

41–50 of 142 posts

Re: Rails 3 Performance - Not Good Enough

#41

Post by nirvdrum »

towelrod wrote: post #38
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…

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 situation where you're guaranteeing an exception is raised during non-exceptional execution flow is generally a bad idea. It may be cleaner or more concise code-wise, but performance-wise it almost certainly will always be slower.

For the most part I believe the parent is correct in that there is a much stronger emphasis placed on code conciseness/clarity than there is on avoiding performance anti-patterns. It's hard to measure whether the gains in "code agility" outweigh the local performance hit by making it easier to surface other performance problems. When there's less code involved it usually follows that it's easier to spot and fix problems. But I worry because my own experience suggests that death of a thousand cuts is a considerably harder situation to get out of than dealing with a handful of gnarlier bottlenecks.

Re: Rails 3 Performance - Not Good Enough

#42

Post by nirvdrum »

xpaulbettsx wrote: post #11

I can't believe that in a modern web app, most of the time wouldn't be spent in the database, those graphs floored me. Other than expanding templates, what in the world is Rails doing with that time??

While not related to these graphs, in general ActiveRecord only performs very rudimentary caching. By default it lasts for the life a single request. There is no shared cache across requests or processes, so if you read in data that hardly ever changes, you're hitting the DB for that data on each request. This was a rather big shock to me when coming over from Java, where I used to use Cayenne* (http://cayenne.apache.org/) for the ORM. Cayenne has some pretty nifty tunable caching features out of the box and I just came to expect those as being a requirement of any serious ORM these days. That was three years ago.

That's not to say there aren't caching options for ActiveRecord or Rails. You just have to go out of your way to employ them. There's no out-of-the-box write-through cache of the DB.

* - I became a committer for the Cayenne project but haven't been active over the past couple years.

Re: Rails 3 Performance - Not Good Enough

#43

Post by DavidChouinard »

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…

Here's the way I look at it: computing is becoming exponentially cheaper, but good developers are incredibly expensive. Anything that makes the later more productive is overwhelmingly likely to be worth an increase in hardware cost (to cover up lost performance).

The problem is that performance is an academically interesting problem to us geeks. We love to optimize, make quicker and oh-so clever.

Re: Rails 3 Performance - Not Good Enough

#44

Post by fauigerzigerk »

towelrod wrote: post #38
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…

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.

Re: Rails 3 Performance - Not Good Enough

#45

Post by fauigerzigerk »

DavidChouinard wrote: post #43
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…

Here's the way I look at it: computing is becoming exponentially cheaper, but good developers are incredibly expensive. Anything that makes the later more productive is overwhelmingly likely to be worth an increase in hardware cost (to cover up lost performance). The problem is that performance is an academically interesting problem to us geeks. We love to optimize, make quicker and oh-so clever.

I think this sharp antagonism between productivity and performance is a fallacy. It only works in the extremes. Making something slow doesn't automatically make it more productive to use. For framework writers to give some thought to performance issues does not make users of that framework less productive.

Also, if you look at what just a few selective type hints in clojure can do to performance or how terse Scala code is, you have to come to the conclusion that performance and productivity can go hand in hand.

Re: Rails 3 Performance - Not Good Enough

#46

Post by btmorex »

DavidChouinard wrote: post #43
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…

Here's the way I look at it: computing is becoming exponentially cheaper, but good developers are incredibly expensive. Anything that makes the later more productive is overwhelmingly likely to be worth an increase in hardware cost (to cover up lost performance). The problem is that performance is an academically interesting problem to us geeks. We love to optimize, make quicker and oh-so clever.

I guess you could take that viewpoint if you're planning on releasing your product 3 years from now (for example, that might be okay for a game developer with long product cycles), but 500ms to render a page is slow today. So, is the idea to wait 5 years so your page renders in a reasonable amount of time?

Re: Rails 3 Performance - Not Good Enough

#47

Post by coolgeek »

lhnz wrote: post #37
fauigerzigerk wrote: post #21

Earlier quoted context omitted.

If I'm writing a framework on which others depend in ways I cannot entirely foresee, then the old features _must_ perform as well or better than before. No compromises.

Out of interest, what language is your framework for? I'm seriously thinking of stopping using PHP because of the weight of the frameworks -- at least on Python there are microframeworks in which I am not left with a massive bottlenecks on the simplest Hello World page. Sure, you can scale but it's becoming ridiculous that I am forced to be so frugal with processor intensive tasks in the rest of the web application j…

http://codeigniter.com/

Re: Rails 3 Performance - Not Good Enough

#49

Post by moe »

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 plenty more - reviewing rails gems for performance is generally an exercise in frustration.

It's a pity. Moore's Law mostly mitigates the low performance of MRI and we could be fine that way. But it can not mitigate a culture of incompetent design.

Re: Rails 3 Performance - Not Good Enough

#50

Post by aneth »

johnb wrote: post #24
fauigerzigerk wrote: post #21

Earlier quoted context omitted.

If I'm writing a framework on which others depend in ways I cannot entirely foresee, then the old features _must_ perform as well or better than before. No compromises.

That position of "no compromises" is probably why you're not writing a framework on which others depend. Complex software always involves compromises, especially general purpose frameworks used by a large population. Even if you're saying that only in performance there can be no compromises (but generally people who say things like no compromises don't bound those statements) it will cause large compromises in other…

jquery is a great counter-example. Every version is significantly faster than the previous one, AND adds features.
Post reply on HN