Hacker News Reader

Comment by mikemike | Hacker News Reader

Some of Ruby's more excentric semantics are really hard to optimize away by a compiler. It takes a much greater effort to compile Ruby source code to machine code of similar quality than for Lua. Since time and money are not infinite resources, especially for compiler development, you'll get worse results in practice.

So, yes, language design does impact performance.

View on HN

> Some of Ruby's more excentric semantics are really hard to optimize away by a compiler.

Any examples in particular? Besides name resolution and method dispatch (and callcc, but I think that may have even been removed from Ruby 1.9) none of Ruby's semantics seem all that different from Lua. Am I missing something?

I guess there's also throw/catch and exceptions.

Mostly resolution and dispatch. Some of this needs very clever caching or the overhead can't be eliminated or hoisted. The control-flow constructs and iterators come to mind, too.

The Rubyists certainly know about these issues, so you'll have to ask them for details.

There's also the over-featured thread implementation (especially before 1.9)

Dispatch is worse than you realize due to the hackish optimizations made in MRI: if you monkeypatch a natively-method from Ruby, other native code will call the original by default.

Here is a step by step comparison on how cutting off ruby's features can make the JRuby implementation faster, from the guy who worked on JRuby.

http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...

Read it, you will find it interesting. The guy also wrote a small language called Duby which used Ruby like syntax but is much more faster, because he didn't include any of those slowing down features.

Reply on news.ycombinator.com