Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Fix Slow Code in Ruby

engineering.shopify.com

Post reply on HN
Print view View original

21–30 of 213 posts

Re: How to Fix Slow Code in Ruby

#21

Post by meesterdude »

stevebmark wrote: post #7

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 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released.

https://news.ycombinator.com/item?id=17220967

Re: How to Fix Slow Code in Ruby

#22

Post by kipply »

ch4s3 wrote: post #6
lidHanteyk wrote: post #4

Interesting; Shopify doesn't use TruffleRuby, but instead prefers MRI?

TruffleRuby can’t quite run Rails yet. They use truffle for some plain Ruby stuff.

Not running most Rails applications is true, but the applications that can be run on TruffleRuby are not quite plain. It can run a web application that serves storefront traffic (source at the end of https://engineering.shopify.com/blogs/engineering/optimizing...)

Re: How to Fix Slow Code in Ruby

#24

Post by joshmn »

sosodev wrote: post #16
ryansouza wrote: post #13

Earlier quoted context omitted.

I guarantee the tradeoffs matter to them

I’ve seen videos on Twitter of the Shopify CEO saying that Ruby’s performance literally doesn’t matter to them. That it’s easy enough to scale it horizontally and the benefits outweigh the cost.

Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.

Re: How to Fix Slow Code in Ruby

#26

Post by saagarjha »

stevebmark wrote: post #7

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…

People used to think JavaScript was too dynamic to optimize, too. Then people poured time and effort into it and now good JavaScript virtual machines can hold their own against competing implementations for other languages.

Re: How to Fix Slow Code in Ruby

#27

Post by yxhuvud »

alberth wrote: post #15

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] [1] https://www.graalvm.org [2] https://www.graalvm.org/docs/faq/ Edit: looks like TruffleRuby is built onto of Graal. https://github.com/oracle/truffleruby

Last time I tried to run Truffle on the company test suite it spent an hour processing 1/8th of the suite. Then it was killed by the OOM killer. On a 32 GB machine. To be fair there was only one or two errors during that, so compatibility is at least getting there.

Meanwhile Ruby 2.6.5 chugs along and finishes the whole suite in 8 minutes. Never hitting any unreasonable amounts of memory.

Re: How to Fix Slow Code in Ruby

#29

Post by joelbluminator »

dijit wrote: post #17
FanaHOVA wrote: post #11

Earlier quoted context omitted.

> 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.

Pedantry aside, we've reached a point in our industry where we can do a lot with horizontal scalability. I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running. But there is a limit, usually in the persistence and caching layers. What you'll find is that those "large scale deployments" are going to have a -lot- of internal cache…

> services running those caches and persistence will not be written in ruby

So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?

Post reply on HN