# Truffleruby Vs. MRI performance comparison **URL:** \ **Category:** rubyonrails-talk\ **Created:** [August 19, 2022, 9:53am UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281 "2022-08-19T09:53:06Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![andre.kullmann](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/andre.kullmann/32/5616_2.png) [@andre.kullmann](https://discuss.rubyonrails.org/u/andre.kullmann)\ **Post date:** [August 19, 2022, 9:53am UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281/1 "2022-08-19T09:53:06Z")
Does anyone had experience with **truffleruby** on rails? It sounds like **truffleruby** will be the future, but still the rails startup _took 4 times longer than expected_. I can’t see any benefit of **truffleruby**. My opinion is based on this small comparison between **truffleruby** and MRI [GitHub - andrekullmann/truffleruby-playground: Playing with truffleruby. Performace and handling](https://github.com/andrekullmann/truffleruby-playground) Thanks for any advice. ---
**Author:** ![Scott\_Jacobsen](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/scott_jacobsen/32/943_2.png) [@Scott\_Jacobsen](https://discuss.rubyonrails.org/u/Scott_Jacobsen)\ **Post date:** [August 19, 2022, 5:28pm UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281/2 "2022-08-19T17:28:27Z")
For most Rails apps, the speed of the ruby interpreter is seldom the bottleneck. I think the main benefit of interpreters like TR and JRuby are the ability to run code in parallel, because there is no global interpreter lock. I don’t think TR is the future. It is a great project, but MRI ruby is progressing full speed ahead, with great enhancements on every release. I think MRI ruby will continue to be the future. ---
**Author:** ![andre.kullmann](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/andre.kullmann/32/5616_2.png) [@andre.kullmann](https://discuss.rubyonrails.org/u/andre.kullmann)\ **Post date:** [August 22, 2022, 6:44pm UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281/3 "2022-08-22T18:44:47Z")
Thanks Scott for sharing your opinion. ---
**Author:** ![nikita](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/nikita/32/5647_2.png) [@nikita](https://discuss.rubyonrails.org/u/nikita)\ **Post date:** [August 23, 2022, 2:05pm UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281/4 "2022-08-23T14:05:14Z")
A little old comment but I believe main concepts are still relevant: > [@Plans for TruffleRuby Support](https://discuss.rubyonrails.org/t/plans-for-truffleruby-support/75381/3): > > Rails 6 should in general work on TruffleRuby, including rails new. Please report to [Issues · oracle/truffleruby · GitHub](https://github.com/oracle/truffleruby/issues) if not. fork() is not currently supported. Puma works well on TruffleRuby and TruffleRuby is tested in Puma’s CI. That said, TruffleRuby doesn’t run Rails tests in CI yet. That would be something valuable to improve on. Application startup and VM startup are quite different things. Right now, TruffleRuby is good at VM startup but not so much at application startup. Curren… So the app boot time and time to reach peak performance are still the main tradeoffs even though the boot time has been improved recently. I’m just far from being the best person to elaborate ---
**Author:** ![Benoit\_Daloze](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/benoit_daloze/32/1569_2.png) [@Benoit\_Daloze](https://discuss.rubyonrails.org/u/Benoit_Daloze)\ **Post date:** [August 23, 2022, 3:10pm UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281/5 "2022-08-23T15:10:17Z")
The application startup is currently expected to not be faster on TruffleRuby. What should be faster is the throughput after enough warmup (and it it’s not, please file an issue at [Issues · oracle/truffleruby · GitHub](https://github.com/oracle/truffleruby/issues)). Please do not say “truffle ruby doesn’t seem like a good choice” based only on startup numbers. Especially for a Rails application, throughput/latency is very relevant and startup is not the only metric which matters. Just like for JRuby or typically any VM with an optimizing JIT using profiling information (e.g. JVM, JS VMs, etc), startup is expected to not be faster. The reason is the interpreter gathers additional profiling information (e.g. which branches are taken, which types are seen, etc), which is later used by the JIT compiler to produce much better code than if there was no profiling information. Gathering that additional profiling information takes time and this is a big part why you see a slowdown on startup. When loading the application there is constantly new code being seen, so even though the JIT is compiling in parallel, there is still a significant amount of time spent in the interpreter. We (the TruffleRuby and GraalVM teams) are working on improving startup/warmup on TruffleRuby and there has already been significant progress with multi-tier compilation, etc. A game changer for this is [Auxiliary Engine Caching](https://www.graalvm.org/22.2/graalvm-as-a-platform/language-implementation-framework/AuxiliaryEngineCachingEnterprise/) which lets you persist the JIT-compiled code and reuse it across processes, so you’d have one profiling run, and then later runs would start fast and run in compiled code almost all of the time. This is not fully supported yet in TruffleRuby but we are currently working on it. ---
**Author:** ![Benoit\_Daloze](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/benoit_daloze/32/1569_2.png) [@Benoit\_Daloze](https://discuss.rubyonrails.org/u/Benoit_Daloze)\ **Post date:** [August 23, 2022, 3:17pm UTC](https://discuss.rubyonrails.org/t/truffleruby-vs-mri-performance-comparison/81281/6 "2022-08-23T15:17:56Z")
> [@Scott\_Jacobsen](#): > > For most Rails apps, the speed of the ruby interpreter is seldom the bottleneck. Do you have any data to back that? I think it’s a common misconception, for instance see [https://twitter.com/\_byroot/status/1557273485516341248](https://twitter.com/_byroot/status/1557273485516341248) > [@Scott\_Jacobsen](#): > > I don’t think TR is the future. It is a great project, but MRI ruby is progressing full speed ahead, with great enhancements on every release. I think MRI ruby will continue to be the future. This is probably not worth arguing too much about (what is “the future” is subjective), but I don’t see significant performance speedups in CRuby, and nothing comparable to TruffleRuby in terms of peak performance. For instance see [Benchmarking CRuby, MJIT, YJIT, JRuby and TruffleRuby · On the Edge of Ruby](https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yjit-jruby-truffleruby.html) which notably includes a rails benchmark.