4 ms·

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://

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/tickets/6695 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.

nirvdrum 15y ago
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.
- towelrod 15y ago
  >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.
  - nirvdrum 15y ago
    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.
fauigerzigerk 15y ago
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.
- towelrod 15y ago
  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".
  - fauigerzigerk 15y ago
    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.
    - towelrod 15y ago
      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.
joevandyk 15y ago
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-initializes-extremely-slow-on-ruby-1-9-2 http://stackoverflow.com/questions/4789248/rails-3-initializ... http://stackoverflow.com/questions/5516428/slow-deployment-for-a-large-rails-3-application-using-ruby-1-9-2 http://stackoverflow.com/questions/5516428/slow-deployment-f... http://www.ruby-forum.com/topic/1569988 http://www.ruby-forum.com/topic/1569988
- joevandyk 15y ago
  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.
  - joevandyk 15y ago
    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.
joevandyk 15y ago
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 http://dl.dropbox.com/u/6607107/dev.tanga.gif 46% of the time is spent garbage collecting.

nirvdrum 15y ago

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.

towelrod 15y ago
>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.
- nirvdrum 15y ago
  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.

fauigerzigerk 15y ago

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.

towelrod 15y ago
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".
- fauigerzigerk 15y ago
  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.
  - towelrod 15y ago
    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.

joevandyk 15y ago

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-initializes-extremely-slow-on-ruby-1-9-2 http://stackoverflow.com/questions/4789248/rails-3-initializ... http://stackoverflow.com/questions/5516428/slow-deployment-for-a-large-rails-3-application-using-ruby-1-9-2 http://stackoverflow.com/questions/5516428/slow-deployment-f... http://www.ruby-forum.com/topic/1569988 http://www.ruby-forum.com/topic/1569988

joevandyk 15y ago
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.
- joevandyk 15y ago
  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.

joevandyk 15y ago

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 http://dl.dropbox.com/u/6607107/dev.tanga.gif 46% of the time is spent garbage collecting.