Live data from Hacker News

How to Fix Slow Code in Ruby

engineering.shopify.com

51–60 of 213 posts

Re: How to Fix Slow Code in Ruby

#52
post #19

Any performance benchmarck of jruby vs truffleruby vs ruby?

https://github.com/mame/optcarrot Includes some rare, bonus ruby implementations too <3

Nice, JIT in 2.6 makes a significant performance jump https://rubybench.org/ruby/ruby/releases?result_type=Optcarr...

Re: How to Fix Slow Code in Ruby

#54
post #39
post #36

Earlier quoted context omitted.

Shopify is actually replacing slow ruby code with Go. And yes they ACK that Ruby is too slow. Also Shopify is a big monolith so it does not help.

A monolith doesn't necessarily mean slower, even with Ruby. There are lots of opportunities to run less code on each request, do some work with the db, and to split off measure bottlenecks into services in a faster language. It's often good to build things quickly, find fit, and then carefully measure before you introduce calls over the network.

A monolith is a problem which they are also breaking down, when you want to make something faster it's easier to target the service that does it vs the giant app.

Edit: getting downvoted by people that don't work at Shopify.

Re: How to Fix Slow Code in Ruby

#55

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 hund…

In my simple relative comparisons of a couple of sample programs, I've found Ruby to be about as fast as, or faster than, Python, and slower than JS.

Re: How to Fix Slow Code in Ruby

#56
post #37

Earlier quoted context omitted.

Also keep in mind that as far as performance of dynamic languages goes, all of the P* languages (Perl, Python, PHP, and... Ruby ;)) have been left in the dust by the front-runners (eg Node.js or LuaJIT). Perl used to be king a long time ago, eventually, PHP took pole position, and maybe now it's Ruby's time to shine. But being leader of that particular pack could mean you're nevertheless still 'slow' depending on con…

I wouldn't put node in with luajit. Luajit is about 4x faster than v8 JavaScript. So it's still in the slow category

Depends on the benchmark. Eg at the bottom of this page [1] can be found a simple fib(40) comparison of a few runtimes.

The Node time is at 2.6x the LuaJIT time, which I'd still consider in the same ballpark compared to eg the factor of 31x achieved by Python3.

[1] https://github.com/wasm3/wasm3/blob/master/docs/Performance....

Re: How to Fix Slow Code in Ruby

#57

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 hund…

Stop painting ruby as slow. In benchmarks i've seen it's handily beat out PHP, which still runs much of the web. the ruby 3x3 goal, of getting running super mario at 60FPS, was if i recall correctly, already reached (or close to it) in ruby 2.6. https://developers.redhat.com/blog/2018/03/22/ruby-3x3-perfo... additionally: > Sinatra + Sequel is already very competitive in web performance with Go > Between Ruby 1.8 and…

"Sinatra + Sequel is already very competitive in web performance with Go"

A lot of the time, that "competitive with X" in web frameworks is because the scripting language has a web server coded in something other than the scripting language. I don't know about that exact stack, but I know that's the case for Node, for instance. The web server is written in C. So when you benchmark a "tight loop" in those languages, you are running 99% C and 1% your scripting language.

Now, that is not a bad thing. It is a valid result, in the sense that it is a good thing for environments to have fast web servers, and nobody cares what the implementation language is... with perhaps the sole exception of this case, where we're trying to compare the performance of scripting languages by their web server implementation. You can't claim "Scripting Language X is fast because it has a fast webserver!" when the webserver isn't written in Scripting Language X.

(A moment's perusal didn't show me what this particular web server is implemented in. If someone can link me to that web server and show it's implemented in Ruby, I'll be happy to eat my words here. But if the performance is comparable to Go, that's enough evidence it isn't written in Ruby to satisfy me until more evidence comes in. If Ruby isn't a slow language, you've defined "slow language" to the point that no language is slow. There isn't much competition in the "slower than Ruby" field; Perl 6 is pretty much the only entrant I know of. There's a number of languages as slow as Ruby, it is not uniquely slow, but there's almost nothing slower.)

Re: How to Fix Slow Code in Ruby

#58
post #40

Earlier quoted context omitted.

Amazing work and really appreciate all you're doing to better the ecosystem. Question: (a) do you believe we'll ever get to a day when TruffleRuby/Graal will be able to 100% run Ruby on Rails and (b) how much faster over MRI do you believe it could achieve?

Compatibility yeah I don't think there's any reason we can't be very close to 100% there. For parts of the Ruby ecosystem running production workloads, such as the Liquid template engine, I see 6x performance today. I think that's a realistic goal in time.

Wow, that's amazing!

Any rough estimates on when the masses will be able to run RoR on TruffleRuby?

(Just order of magnitude timing ... e.g. late 2020, mid 2021, etc.)

Re: How to Fix Slow Code in Ruby

#59

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 hund…

> Is it "slow" enough to matter? Probably not until you get to a medium scale. Phew, I'm glad GitHub and Shopify's scale is still small.

> Phew, I'm glad GitHub and Shopify's scale is still small.

Phew, good thing they can afford to burn a lot of cash for hosting.

Re: How to Fix Slow Code in Ruby

#60

Earlier quoted context omitted.

Why?

Because crystal lang has all of the main syntax and features that people love about Ruby, but it's way faster because of the typing and compiling. "Fast as C, slick as ruby"

The compiler would have to dramatically increase in speed to make it effective. I tried using Crystal to build a small app using Amber or Lucky frameworks. They weren't fast enough for a flowing edit/compile/run workflow. Ended up using Kemal which is like Sinatra and nowhere like Rails.
Post reply on HN