First thing I tell anyone when they say "this code is slow because of X" is to profile it. Profile, profile, profile! More often than not your assumptions are wrong.
There's a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There's definitely a jump between making guesses and hoping you improve performance vs truly understanding what your code is doing.
What's current state on GraalVM as it relates to running production Ruby code?
From what I understand, it's the fastest VM out there at the moment for Ruby.
And yes, it's from Oracle but they have GPL'd the code [2]
[2] https://www.graalvm.org/docs/faq/
Edit: looks like TruffleRuby is built onto of Graal.
I even have a little method in my .pryrc that lets me easily benchmark on the fly in the console
def benchmark_time(repetitions = 100, &block) require 'benchmark' Benchmark.bm{ |b| b.report{ repetitions.times(&block) } } end
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language.
Ruby used to be able to say we sacrifice performance for developer productivity.
I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing wildly more performant code.
Benchmarks are subjective, but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower.
It fundamentally has to be slower. Ruby is the most dynamic of the dynamic programming languages. And the community has embraced metaprogramming, making it every more dynamic. Especially on webservers, you'll be executing hundreds, sometimes thousands, more lines of code than other servers, especially in a mature system.
Is it "slow" enough to matter? Probably not until you get to a medium scale. Everywhere I've worked, we've had to on average double the hardware specs for Ruby servers to make them as performant as other dynamic language applications we run. Not the most expensive thing in the grand scheme of things, but there are entire cottage industries of magically tuning Ruby and Rails that you don't have to worry about with other systems until much larger scales.
Tuby is almost the only language which has a really really good, clear and well thoughout standard library.
Interesting; Shopify doesn't use TruffleRuby, but instead prefers MRI?
Any performance benchmarck of jruby vs truffleruby vs ruby?
Stop using Ruby?
I wish we could just take Ruby, scrap it, and as a community replace it with Crystal Lang
C++
It's that easy :)
Seriously, if you need high performance out of the box, you should probably just skip Ruby. I love that language to death but most of the time you cannot use of it for a decent scale.
There’s a much easier way: just increase `Rails.application.speed` from 5 to 10 in the application config.
...Rewrite in almost anything else and you'll have fast code. :)
It's quite amazing the lengths the companies will go to just to avoid changing their status quo. But for them it makes sense.
---
EDIT: Downvoters, calm down. Ruby on Rails is objectively quite a slow framework and this is proven in many public benchmarks (Techempower included). And Ruby isn't the fastest among the dynamic languages either.
Less cargo culting and more facts, please.
Really surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query.
In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if you can't, a faster language will not help you).
I'm sure there are extremely high-performance or high-scale points where language choice starts to matter more, but I'm also not surprised if Shopify is correct not to think they're there yet.