5 ms·
Is the Rails performance something to do with the amount of meta programming going on - I can imagine that being hard to optimise!
by klelatti 5y ago
Is the Rails performance something to do with the amount of meta programming going on - I can imagine that being hard to optimise!
- joelbluminator 5y agoWell YJIT succeeded to improve Rails by 30% in a year , so it IS possible. https://speed.yjit.org/ https://speed.yjit.org/
- eregon 5y agoIt'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)
- ch4s3 5y agoI'm not sure. If Chris Seaton pops into the thread, you should ask him.
- eregon 5y agoActually 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.
- klelatti 5y agoThanks 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?!
- eregon 5y agoYes, 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.
- klelatti 5y agoThanks again and of course for Truffleruby!