# Re: How to speed up ruby and make it as fast as possible **URL:** \ **Category:** Ruby\ **Created:** [July 14, 2006, 11:08pm UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98471 "2006-07-14T23:08:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![jamal86](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jamal86](https://www.ruby-forum.com/u/jamal86)\ **Post date:** [July 14, 2006, 11:08pm UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98471/1 "2006-07-14T23:08:23Z")
I think you’ve hit the nail on the head: execution speed is apparently a sore spot in the Ruby community, one that results in undue defensiveness and shooting the messenger! From my reading, Perl and Python are the primary competitors to Ruby among programming languages at this time. I prefer the elegance of Ruby, and want it to be chosen over the others when potential users are making such a decision. Whereas Python cannot change its indentation requirement (and remain Python) and Perl (version 5) cannot change its messiness, I believe Ruby is capable of reaching a comparable level of execution speed. Solving a problem is usually better accomplished by acknowledging it openly rather than causing people to feel like they have committed heresy or stupidity by raising it. Regards, Jamal ---
**Author:** ![jamal86](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jamal86](https://www.ruby-forum.com/u/jamal86)\ **Post date:** [July 14, 2006, 11:30pm UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98471/2 "2006-07-14T23:30:56Z")
On Sat, 15 Jul 2006, Jamal M. wrote: > Python) and Perl (version 5) cannot change its messiness, I believe Ruby > is capable of reaching a comparable level of execution speed. Solving a > problem is usually better accomplished by acknowledging it openly rather > than causing people to feel like they have committed heresy or stupidity > by raising it. I don’t think that’s it. The common speed complaint on this list stems from someone looking at some benchmark or another. They see Ruby places behind language X, so they complain about it. But performance is really far more complex than that. For example, consider PHP4. On paper, with benchmarks, it is faster than Ruby, and simple benchmarks put it much faster than Ruby for the things PHP is good at – dynamic web content. But…go download a PHP MVC framework like CakePHP (which is a pretty nice piece of PHP). Now compare it to a Ruby framework. Suddenly the benchmark numbers start changing, dramatically. My tests with IOWA show a speed difference of about 4x Ruby’s favor when comparing CakePHP under PHP4 to IOWA under Ruby 1.8.4. So which language is truly faster? I think a person is hard pressed to find an application which will perform acceptably under Perl or Python, but which will not under Ruby. So while additional speed is nice, I have yet to be convinced that it is the big deal that some people keep trying to make it. Kirk H. ---
**Author:** ![jamal86](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jamal86](https://www.ruby-forum.com/u/jamal86)\ **Post date:** [July 15, 2006, 2:02am UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98471/3 "2006-07-15T02:02:08Z")
Jamal M. wrote: > than causing people to feel like they have committed heresy or stupidity > by raising it. The real point is: Speed is only a problem if you think it is. I’ve used Ruby for more than six years, and have never had a problem with speed. What annoys me is people getting in my face and saying that I’m “ignoring the problem.” I’m not. For my purposes so far, there isn’t a problem. Everyone, nyself included, would like Ruby to be faster. But I don’t condone alarmists running around squawking about their own problems as if they were everybody’s problems. Some people find Ruby “unusable” because of its speed. Those people should use something else until Ruby is fast enough. (And/or they should contribute to making Ruby faster.) However: Many, many people don’t find Ruby “unusably slow.” As I said, I have never had an application where Ruby’s speed was a real problem. (Once, four years ago, I had an app that took several minutes to run. But it needed to run very rarely. If I were running it several times a day, then it might be an issue.) So in short, anyone is welcome to consider Ruby “slow” in a given context. But don’t say that it’s “slow” in every context, or that there is a “problem” that I’m “ignoring.” Hal ---
**Author:** ![jamal86](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jamal86](https://www.ruby-forum.com/u/jamal86)\ **Post date:** [July 16, 2006, 3:42pm UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98471/4 "2006-07-16T15:42:35Z")
On 2006-07-14, Hal F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The real point is: Speed is only a problem if you think it is. Matz thinks it is. He’s said so elsewhere in this thread. > I’ve used Ruby for more than six years, and have never had a > problem with speed. It’s good that you have not had this problem. > What annoys me is people getting in my face and saying that > I’m “ignoring the problem.” I’m not. If someone asks “this Ruby script is too slow for my purposes, how can it be faster” and is only told “write it in C”, I think they can reasonably say that _their_ problem is being ignored. > Some people find Ruby “unusable” because of its speed. Those > people should use something else until Ruby is fast enough. > (And/or they should contribute to making Ruby faster.) Which is why I asked if YARV is the way to go. If I knew that I could see if I could help. But (/me sighs) nobody answered that. Anyway I’ve just downloaded and benchmarked YARV and it’s very impressive. Many times faster on most benchmarks, merely comparable on a few. If anyone has tips on helping YARV, I’m all ears. Regards, Jeremy H.