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

31–40 of 142 posts

Re: Rails 3 Performance - Not Good Enough

#31

Post by fauigerzigerk »

asomiv wrote: post #29
fauigerzigerk wrote: post #28

Earlier quoted context omitted.

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.

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.

Re: Rails 3 Performance - Not Good Enough

#32

Post by johnb »

fauigerzigerk wrote: post #28
johnb wrote: post #24

Earlier quoted context omitted.

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…

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.

Re: Rails 3 Performance - Not Good Enough

#33

Post by justincormack »

nametoremember wrote: post #26

I DON'T want to start a flame war or anything, but how does this hold up to Django and PHP frameworks like cakephp and Zend?

Why dont you meeasure it? His microbenchmark basically measures the time to do 10000 database round trips to extract a field. So long as you dont overoptimise and request all the data in a single transaction.

Re: Rails 3 Performance - Not Good Enough

#34

Post by pilif »

sgrytoyr wrote: post #16
banditaras wrote: post #13

https://github.com/rails/rails/commit/86acbf1cc050c8fa8c74a1... For our application that meant bringing 1 of 3 application servers down and slowing things down in general. So we're stuck with 3.0.5. From what I understand the Rails community has declared 1.8.x as a thing of the past (tbf it IS a thing of the past. But in a non-perfect world migrations our not always easy). This may be a good thing (it forced us to ma…

That commit made certain pages of my app about 10 times slower. This was such an appalling performance degradation that I had to do some digging: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/... https://gist.github.com/919428 https://github.com/rails/rails/commit/a3639be4ed5e89b59c4ad0... The commit mostly fixes that particular issue (and is included in 3.0.7), but as the article point out Rails 3 AR p…

Judging by the comments on that commit and the comments in this HN post, I would say that many of the performance regressions are only happening under ruby 1.8.x.

By this time, I wonder what the rails developers should spend their time with: making the framework better for people running the current version of the language or fixing performance problems due to shortcomings of the old version?

If you can't upgrade to 1.9 and the performance of rails 3 isn't good enough for you to upgrade rails, why don't you just stay with 2.3 and upgrade once you are ready to move to ruby 1.9?

That way your unwillingness to upgrade ruby doesn't "waste" the time of the rails developers by causing them to fix issues that don't even apply to more and more people over time.

Note: i'm talking about regressions that only affect 1.8

Re: Rails 3 Performance - Not Good Enough

#35

Post by fauigerzigerk »

johnb wrote: post #32
fauigerzigerk wrote: post #28

Earlier quoted context omitted.

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…

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.

Re: Rails 3 Performance - Not Good Enough

#36

Post by nametoremember »

justincormack wrote: post #33
nametoremember wrote: post #26

I DON'T want to start a flame war or anything, but how does this hold up to Django and PHP frameworks like cakephp and Zend?

Why dont you meeasure it? His microbenchmark basically measures the time to do 10000 database round trips to extract a field. So long as you dont overoptimise and request all the data in a single transaction.

Hmm, I've never benchmarked anything before but I guess I will give it a go. (After my exams!)

Re: Rails 3 Performance - Not Good Enough

#37

Post by lhnz »

fauigerzigerk wrote: post #21
comice wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: Rails 3 Performance - Not Good Enough

#38

Post by towelrod »

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

Re: Rails 3 Performance - Not Good Enough

#39

Post by rhizome »

philjackson wrote: post #20
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…

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.

Re: Rails 3 Performance - Not Good Enough

#40

Post by fauigerzigerk »

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…

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.

Post reply on HN