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

Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

railsatscale.com

Post reply on HN
Print view View original

51–60 of 158 posts

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#51

Post by bmulholland »

nomilk wrote: post #17
Ocha wrote: post #12

Earlier quoted context omitted.

Super easy and have not had an issue with it in over 10 years of using it. There is an example here on how to do it with docker image. https://mailsnag.com/blog/optimized-ruby-dockerfile/ .

Going to try this right now! Will report back. OOC, why isn't this part a ruby default? Isn't it always better to be more memory efficient. (I'm trying to understand what the trade offs are, if any) EDIT: well, exactly 6 minutes later, I'm done. I followed these instructions: https://elements.heroku.com/buildpacks/gaffneyc/heroku-build... The app seems to work like usual, I'll just have to wait and see what happens t…

Yeah, I had the same reaction last week. It's not a Ruby default because some versions of Linux can't use it. ¯\_(ツ)_/¯

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#52

Post by cowsandmilk »

elif wrote: post #25
cowsandmilk wrote: post #22

Earlier quoted context omitted.

Well, Shopify is investing in optimizing Ruby, so they believe Ruby was the component with the most opportunity for improvement. And the results are showing there was indeed lots of places where improvements could be made.

That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture

> The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing.

Most companies don’t have unlimited budgets. Performance-oriented organizations profile and then spend money where profiling tells them to. Shopify isn’t hiring people to contribute to MySQL or Redis internals. They hired a full team to work on Ruby internals, not just creating YJIT, but also on CRuby’s memory layout, hiring the lead on TruffleRuby, and funding academic programming language research on Ruby.

No company has an infinite budget to “optimize everything”. It is clear where internal performance testing pointed Shopify (at Ruby) and with double digit gains being extracted year after year, their profiling didn’t lie. And other Ruby on Rails shops are seeing similar double digit performance wins, not on fake benchmarks, but on actual page load times and traffic that can be handled by a server.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#53

Post by pjmlp »

berkle4455 wrote: post #30
rapsey wrote: post #28

Earlier quoted context omitted.

Ok now what is the cost of all the instances. And how many instances would be required if Go/Rust would have been used? Also what is the cost in man hours spent on optimizations and profiling.

> And how many instances would be required if Go/Rust would have been used? Zero. Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006, and they would never have gotten off the ground and been another failed techbro startup that instead of getting shit done, bikeshedded over languages. PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.

Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#54

Post by nik736 »

phamilton wrote: post #45
netheril96 wrote: post #35

Earlier quoted context omitted.

> Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006, > PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined. You already stated the obvious: PHP and Ruby apps generated far more revenues simply by existing longer.

I also question the revenue claim. Google has a lot of revenue. Pinterest, Hashicorp, Uber, Twitch, Dropbox, etc. all have a good amount of golang and collectively have a lot of revenue. It might need a few more years to tip the scale, but it's closer than suggested here.

Twitch was initially built with Ruby on Rails as well.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#55

Post by rapsey »

ChadMoran wrote: post #21
Gigachad wrote: post #13

Earlier quoted context omitted.

You don't even have to write performant code. You can just start as many instances of the rails app as you want. The bottleneck is usually the database.

Each request gets its own server! Wait isn’t that lambda?

Rails has always been ahead of the curve.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#57

Post by BytesAndGears »

cyclotron3k wrote: post #39
rapsey wrote: post #32

Earlier quoted context omitted.

That was then and this is now. If you are building under endless VC money go ahead burn it. Most of us however do not have endless stacks of money to burn runing our code.

If you think time-to-market, and overall cost are going to be improved by building your vanilla website in Rust or Go, vs Rails, then I think you may be surprised

Yeah it’s nearly the main benefit of Ruby/Rails that you can spin up an mvp of your company in like a week, and have a decent feature set within a couple months.

The trap is when you start growing and it is hard to change. Because the features that took 1-2 months in RoR might take 3-4 months (or more!) to port to another language, and do you really want to stop your working business when it isn’t a problem?

Because Rails performs totally fine at small-mid startup scale. It’s only when you start getting a couple years old with lots of users that it starts to bite you. But at that point you already have gotten further than 90% of startups ever even make it. And at that point, honestly there are solutions for that too, like gradually pulling the poor-performing bits out into faster languages.

Writing this as someone who works for a startup that uses RoR, and I’ve seen it blow up over several years. I curse RoR daily because it pisses me off, but I don’t think this company would’ve gotten this far if it didn’t have the RoR speed at the beginning.

So are you better off starting your company on Go/Rust/Java? Maybe. But if getting to market fast will help you win, it’s hard to beat RoR.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#58

Post by rapsey »

BytesAndGears wrote: post #57
cyclotron3k wrote: post #39

Earlier quoted context omitted.

If you think time-to-market, and overall cost are going to be improved by building your vanilla website in Rust or Go, vs Rails, then I think you may be surprised

Yeah it’s nearly the main benefit of Ruby/Rails that you can spin up an mvp of your company in like a week, and have a decent feature set within a couple months. The trap is when you start growing and it is hard to change. Because the features that took 1-2 months in RoR might take 3-4 months (or more!) to port to another language, and do you really want to stop your working business when it isn’t a problem? Because…

It is not 2006 anymore. Rails was a trailblazer. The productivity difference is not as large as it was compared to alternatives.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#59

Post by lloeki »

alberth wrote: post #44
elif wrote: post #25

Earlier quoted context omitted.

That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture

No one disputes that Ruby is slow. But you picking “mirrors” in your analogy makes it sounds like a premature optimization. The reason why perf isn’t typically an issue with Rails is the design pattern is to leverage heavy caching. The use of caching is to address the slowness of Ruby.

The two major areas where caching is used in Rails are:

- database queries

- template rendering

First one because round trip to db + running the query + allocating ORM result objects that otherwise get thrown away.

Second one because allocating a ton of strings that get join'd and thrown away.

> No one disputes that Ruby is slow.

I am, because the blanket statement doesn't make sense without context. Also that view is largely biased by the typical assumption that Ruby == Rails.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#60

Post by moonchrome »

pjmlp wrote: post #53
berkle4455 wrote: post #30

Earlier quoted context omitted.

> And how many instances would be required if Go/Rust would have been used? Zero. Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006, and they would never have gotten off the ground and been another failed techbro startup that instead of getting shit done, bikeshedded over languages. PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.

Or they could have used something available in 2006, like C++, Java, .NET/C#, OCaml, Haskell, D.

C# in 2006 was a joke, probably worse than Rails in performance. This was the webforms era and old EF - meant for enterprise customers with a couple of hundred active users max... ASP.NET being a competitive/performant framework is a very recent development (since core basically which became usable past 2.0)

Haskell, OCaml and D are niche languages, probably aren't mature enough now to use for a production system that needs to scale (in terms of org growth and building complex systems).

Java web frameworks were also terrible in 2006 (this is the Java era that gave Java it's reputation) and the only thing worse for productivity I can think of is C++ hahaha ...

Post reply on HN