Hacker News Reader

Comment by ch4s3 | Hacker News Reader

It isn't 100% MRI 3.0 compatible[0] and wasn't able to run Rails at first. It's also not always faster for Rails which occupies a lot of Ruby mindshare.

[0] https://github.com/oracle/truffleruby#current-status

View on HN

Is the Rails performance something to do with the amount of meta programming going on - I can imagine that being hard to optimise!

Actually TruffleRuby optimizes metaprogramming more than any other Ruby implementation. Rails is not the issue, big codebases is the issue: more code = more chances to use something which is not so fast on TruffleRuby yet = more chance to become a bottleneck and degrade the overall performance.

Thanks for the thoughtful and insightful responses. Understand that a large code base is hard - your point here though presumably means that some things in truffleruby are significantly slower than CRuby to cancel out the gains. Or have I misunderstood?!

Yes, some things are slower. Most of them I'd say are unexpected performance bugs. I'd think most are easy to fix once investigated, but some can be hard to fix (recent example, `File.read` is quite fast on CRuby).

Some things are expected to be slower, for instance constantly redefining (monkey-patching) methods or constants is slower on TruffleRuby, but that's typically because the program is broken and so it'd be slow on CRuby as well.

Thanks again and of course for Truffleruby!

I'm not sure. If Chris Seaton pops into the thread, you should ask him.

Well YJIT succeeded to improve Rails by 30% in a year , so it IS possible. https://speed.yjit.org/

It's the same benchmark in the blog post, `railsbench`. So TruffleRuby already speeds up some Rails apps like that one but not every Rails app/program. (TruffleRuby 3.27x, YJIT 1.33x on railsbench)

Reply on news.ycombinator.com