# Re: How to speed up ruby and make it as fast as possible **URL:** \ **Category:** Ruby\ **Created:** [July 14, 2006, 10:38pm UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98466 "2006-07-14T22:38:32Z")\ **Posts on this page:** 1\ **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, 10:38pm UTC](https://www.ruby-forum.com/t/re-how-to-speed-up-ruby-and-make-it-as-fast-as-possible/98466/1 "2006-07-14T22:38:32Z")
Hi Bill, I appreciate the more constructive tone. By the way, I was unfamiliar with the term “troll” in this context, so looked it up on Wikipedia. Let me assure you that I am not seeking ways to be inflammatory, and certainly have not disguised my identity. You say you jumped into the middle of the threat, so may not be aware that I did not make the sweeping statement that Ruby is too slow for real world applications. I agree that its speed is adequate for many applications. How to categorize application areas is difficult, and almost any such attempt would be subject to criticism. Your example about 3D graphics is, indeed, a good illustration of one that would not be suitable for Ruby. I like dynamic scripting languages for productivity and do not expect them to accomplish tasks that require the performance of C. My main interest is in developing what are sometimes called business productivity applications, applications that could be developed, say, with Visual Basic 6. For example, I have written an advanced text editor with the WxRuby library. I loved the rapid application development that Ruby helped to facilitate. There are sometimes noticeable delays, however, in the processing of events by the user interface, e.g., keyboard events. My experience with other scripting languages suggests that such delays are not inevitable with a contemporary scripting languageand modern machinery, so I hope that Ruby’s speed can be improved enough to eliminate these problems. I realize that a speedier algorithm might exist, but the search for it and redesign if found also involve development time taken away from other efforts to advance the application. Ruby Speed improvements, combined with the ability to create truly stand-alone Windows executables, are, in fact, important enough to me that I would pay for commercial Ruby tools that delivered these features. Knowing of such market demand by me and others, there may be Ruby entrepreneurs who respond accordingly. On the other hand, if those of us who need better performance are discounted for raising such concerns, an impression may be left that the current language projects and timelines are adequate. This is not to put blame on the core language developers, but to better convey the extent of interest in such enhancements to the Ruby development environment. Regards, Jamal