Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

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 that's known statically is checked billions of times at runtime they don't care.

For a framework, the concept of premature optimization makes no sense.

View on HN

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.

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.

You could be criticising any memory managed programming language.

No, I'm explicitly criticizing Ruby. I've spent years in Python-land and the average code quality (and btw documentation standard) is much higher over there. Which is not to say Python doesn't have its own problems, but less so in this particular area.

say that the average rubyist is much more concerned with good design than, say, your average java dev.

Good design is a relative term. In ruby I frequently see it interpreted as: Pack as many layers of magic as possible, and then test that with as many layers of testing-frameworks as possible.

That's not too different from the common architecture-astronouting in java. One could argue it's just a different flavor. In either ecosystem the implementation of the actual business concerns ("What does this code actually do?") too often feels like an afterthought.

Disclaimer: I'm not condemning either language. I like Ruby and use it a lot, but this is one aspect that I can't ignore.

> Good design is a relative term. In ruby I frequently see it interpreted as: Pack as many layers of magic as possible, and then test that with as many layers of testing-frameworks as possible.

I have the same feeling sometimes. I wish the Ruby community would not be so concerned with magic and aesthetics, and target clarity.

From experience and observation, I'd say that in most developer communities (include Rubyists) aesthetics and clarity are one and the same..

I'm referring really to functional clarity. Fancy ruby DSLs that invoke method_missing and parse function names make for aesthetically pleasing end user code, but obfuscate the functionality for anyone unfamiliar with the code base.

Aesthetics and clarity are most certainly different in other ways (think pretty sites vs simple clear sites) but that's another discussion.

I've never ever gotten why people get so mad that the database gets hit on every request. It's going to get hit anyway on every request for something else. I've seen how easy it is to break into systems that don't re-auth the user on each request. I guess I just feel like people spend an inordinate amount of time worrying about database performance. A single select from a single table shouldn't be a performance bottleneck. It seems to me that a good database will have that query cached in memory. It may sound "icky" but if you look at the times, I bet your Rails app spends way more time in the renderer than it does for the "select users.* from user" that it uses to populat current_user.

I'm happy to be proven wrong, but I've written a lot of apps before I moved to Rails, and we used to avoid re-authing the user / looking it up on each request, and it's just never made a bit of difference to us.

Query execution time is only part of the equation. But even that gets ugly fast when you have locking going on. E.g., try adding an index to a non-trivially sized table in MySQL and see how fast that (unnecessary) SELECT performs.

We're a postgres shop and the problem we've run into lately is just the sheer number of open connections to the DB. Using something like PgBouncer helps tremendously, but it still is contingent on there being idle connections. Certainly read slaves could be thrown at the problem, too. But it's mounting complexity for something that isn't all that necessary shrug

> 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?

The goal of abstraction is not to prevent you from knowing what's going on underneath the covers. It's generally to allow you to work on the whole with higher level constructs.

It makes a great deal of sense to understand the complexity you're abstracting away, first. Otherwise, you never really know what you're doing. At the end of the day, you're executing on a computer and you're doing yourself a serious disservice if you're ignoring that fact and hoping either Moore's Law or horizontal scaling are the answer.

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

I'm not convinced analogies such as this are particularly useful.

I'm pretty sure you could design a perfectly good car by treating an engine as a black box with a clearly defined set of inputs an outputs without caring how those inputs are translated in the outputs. Which is the goal of a framework such as rails.

But I doubt that you could maintain it without knowing how it worked. The moment anything went wrong, you would be in trouble.

I'm sure you could build a car that looked pretty, but not one that ran well.

Out of curiosity, to which "popular rails auth framework" are you referring? Devise? Authlogic?

Clearance probably. It's really not a big deal with the index in place and it gives you more flexibility for revoking access to specific users without blowing out everyone's cookie. In practice, it's not a big deal performance wise. In a system where it would matter, you'd probably be past the point of an off-the-shelf gem being a good solve.

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" critique? I think the "real problem" is that there are two major releases of MRI Ruby (not to mention JRuby) that have very different performance characteristics.

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.

>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.

I don't really know what your background is, so apologies if I come off as patronizing. If you aren't familiar with how exception handling works under the covers, I encourage you to spend some time looking into it. It's really quite interesting and will likely impact your future design decisions in some way. Learning about longjmp and setjmp clarified a lot of things for me.

Now, I could be completely off-base and 1.9.2 may be the only system out there that has managed to make exception handling a cheap operation. But I'm highly skeptical of that. I think the more likely scenario is exception handling is much cheaper in 1.9.2 than 1.8.7, but still not cheap enough to favor over virtually anything else. I've not read anywhere in the linked issue or in the following comments that suggests using responds_to? was any slower than handling a NoMethodError exception. If it is, that largely points at a failure of responds_to? more than it trumpets the speed of ruby exception handling. And pretending that exception handling is fast enough for flow control and thus other problems needn't be fixed can land a community in serious trouble.

Now obviously there are exceptions to every rule. But the default position of any programmer really should be to reserve exceptions for exceptional circumstances because they are almost axiomatically slow, regardless of language or platform.

Ruby 1.9.2 has its own problems, especially with application startup. My application takes something like 45 seconds to boot on 1.9.2, on 1.8.7 REE it took 20 or so (which still sucks).

http://stackoverflow.com/questions/4789248/rails-3-initializ...

http://stackoverflow.com/questions/5516428/slow-deployment-f...

http://www.ruby-forum.com/topic/1569988

Just ran some benchmarks on a larger rails 3 application (30k lines code, 55 gems).

In Ruby 1.9.2 (p180 and -head), the application starts 26 seconds. In REE 1.8.7, it takes 8 seconds.

I have a very view heavy page. I'm running in development mode.

With 1.8.7 REE's garbage collection settings tuned, the page renders in two seconds.

With 1.9.2, the page renders in four seconds.

Here's what perftools.rb gives me for a view-heavy page on 1.9.2-p180 with Rails 3:

http://dl.dropbox.com/u/6607107/dev.tanga.gif

46% of the time is spent garbage collecting.

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".

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.

To be clear, I don't think that the NGIN slowdown is caused by this exception stuff, because that has been taken out and was really a different performance problem altogether. I only raised it because it was similar -- a problem only on 1.8.7 that was fixed as soon as someone mentioned it.

I think it is very interesting that the specific test produced in the original post is actually faster under Rails 3 and Ruby 1.9.2 than it is under Rails 2 and 1.8.7.

My only grief with you, fauigerzigerk, is that you claim the Rails team doesn't "give a shit about performance", when the performance problems seem to be related to people using an older version of Ruby. I think you are making an extraordinary claim -- that the rails team doesn't "give a shit", in in fact, they clear do give a shit.

I'm sure there are some individuals who do care. But the design of Rails and similar frameworks is consistent with what the benchmarks show. They have to be dog slow and they are. I want to assume that this is out of choice, not out of incompetence, hence my conclusion that they don't give a shit. I'm astonished (and actually pleased) to meet so much resistence. Most of the time I just get to hear something about how speed doesn't matter.

You'd never release a new version of anything that was slower?

What if the new thing had 100x more (useful) features, should it still be as fast?

Performance is a trade-off and sometimes it's worth compromising.

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 areas, such a future feature development or long term maintainability and readability.

Perhaps you should leave comments about my personality to those who actually know me. But if you insist on talking about character traits, let me say this to you: People who don't know where to compromise and where not to comproise generally make bad software.

That's a fair call - I don't know you and I am speaking about character traits.

I don't feel your original comment reflected a position on knowing where to (or not) compromise, you made a strong assertion to take one option off the table in all situations.

In my experience, developers who are make blanket rules up front about what can and can't be changed in the future development of a system don't end up making much of value.

That's just my perspective, and I apologise if I've misread your character.

What I really wanted to express is a dissatisfaction with a general attitude among some framework makers towards performance. Of course there are exceptions to every rule. If the slowdown of ActiveRecord was down to fixing a dangerous security bug or possible loss of data, that would be such an exception. But piling on new features in a way that degrades performance needs to stop somewhere. Hard constraints are good to focus the mind even if you accept rare exceptions.

Compromises from whose point of view? One man's good compromise is another man's bad compromise.

All I can do is state my own point of view as clearly as I can. And my point of view is already a compromise. I didn't say make it as fast as possible even if you have to rewrite it in assembly. I didn't even say, don't write it in Ruby. All I said is don't make it significantly slower than it was before. That doesn't seem like such a big ask.

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

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 just because of the framework.

My own framework and ORM writing days are long past and the software I write nowadays has very different constraints (data/text mining).

I totally share your sentiment about having to be frugal because of wasteful frameworks. My approach is to prefer libraries over frameworks. I start out using the most bare-bones configuration possible (no frameworks, no ORM, no CMS, etc) and then I selectively add well maintained libraries created by people whose attitude I understand.

I think code reuse is generally overrated, particularly when it comes to the rather trivial things that web frameworks do.

This is probably not very helpful to you. I apologize.

http://codeigniter.com/

I don't have the links now, but both Google and Amazon have concluded that faster page loads result in more sales/conversions. If you want to render the whole page in the browser in a couple of seconds (Google webmaster tools indicates the "fast" threshold at 1.5 seconds), spending over half a second on the server-side seems like a big penalty.

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.

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?

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 written in C and is quite fast, if not small.

Bag on Perl all you like as a language, I know I do (and I use it, as well as Rails), but if you can get past the language hump mod_perl will knock you sideways. You can easily pump out a network card's worth of static content with a leftover desktop machine, and DBI is no slouch when it comes to integrating dynamic content.

Slashdot, Valueclick, Craigslist, IMDB...all mod_perl.

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.

I don't see how you would come to that conclusion.

Reply on news.ycombinator.com