How to Fix Slow Code in Ruby • Hacker News Board

Re: How to Fix Slow Code in Ruby

#211

Post by byroot » Thu, May 21, 2020, 3:47 PM UTC

Thaxll wrote: post #54

ch4s3 wrote: post #39

Earlier quoted context omitted.

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.

I work at Shopify. I can confirm that what you are saying is totally false.

Re: How to Fix Slow Code in Ruby

#212

Post by AndyMaleh » Thu, May 21, 2020, 4:54 PM UTC

chrisseaton wrote: post #8

lidHanteyk wrote: post #4

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

> Interesting; Shopify doesn't use TruffleRuby, but instead prefers MRI? Shopify's investing in TruffleRuby as well as MRI - they employ me to work on it. We have it able to run one major app, but still working on making it as fast as we'd like.

Idiotic. That’s what using the right tool for the job is all about. Ruby isn’t for everything and never will be. Just stick to CRuby (or JRuby if integrating with the JVM). They’re already stable. No point diluting the space with more rubies for superficial reasons like lessening the performance trade off in Ruby when there are many many other languages better suited for high performance algorithms to apply where needed. That’s what good engineering is all about after all. Knowing trade-offs and choosing the right tool for the job, not denying them or trying to fight them like TruffleRuby idiotically does. Shopify is like Canada’s Groupon. The only reason they are profiting is because they have a simple business idea despite their mediocre engineering skills.

Re: How to Fix Slow Code in Ruby

#213

Post by yxhuvud » Sun, May 24, 2020, 8:33 AM UTC

chrisseaton wrote: post #31

yxhuvud wrote: post #27

Earlier quoted context omitted.

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.

Yes TruffleRuby struggles to run test code because it works against the optimisations we add to make production code fast. For example when you add more profiling to better optimise the hot code it makes the cold code slower, and tests are almost all cold code. Also our C extension emulation layer used to be extraordinarily slow while we made it work correctly, and it's still rather slow. It's a challenge but we're w…

I'm not certain I buy that argument. Yes, the actual code of each test would be slower than usual, but the things around it, test harness, factories etc should get plenty of execution. And at least in our not so very good test code base, that is where most of the time is spent.