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

41–50 of 158 posts

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

#41

Post by phamilton »

mabbo wrote: post #16
choilive wrote: post #14

Earlier quoted context omitted.

Sure.. but isn't that a database problem and not a rails problem?

No, they both matter. The database can handle X shops per partition, and the rails host can handle Y shops per partition. If rails were half as fast, you'd need twice as many rails hosts (but no more databases).

> but no more databases

Sort of. Twice as many rails hosts means more DB connections which generally means more load/memory on the DB or more load/memory on the external connection pooler.

It's only a bit of incremental load, but it's easy to overlook how many other systems need to run to make Rails scale.

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

#43

Post by elif »

pmontra wrote: post #36
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

I understand that it's a metaphor but F1 teams did really optimize side mirrors more than once, leading to controversies Mercedes 2022 https://www.the-race.com/formula-1/mercedes-2022-f1-car-make... Williams 2019 https://www.autosport.com/f1/news/williams-modifying-front-s... Ferrari 2018 https://www.autosport.com/f1/news/how-ferraris-formula-1-mir...

Of course, most teams do. Some teams have had 2 revisions to side mirrors this season.. and of course it didn't decide the WC, which is my point. Organizations don't merely optimize "the bottleneck" they optimize everything worth optimizing.

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

#44

Post by alberth »

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

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.

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

#45

Post by phamilton »

netheril96 wrote: post #35
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.

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

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

#46

Post by stevebmark »

nindalf wrote: post #37
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.

Rails was a great choice for Shopify, GitHub and Stripe, no doubt. No one is questioning that. GP’s sarcastic “rails doesn’t scale” implies that it would also be a great choice for people starting afresh in 2023. The reply asks for a comparison with other languages popular in 2023, especially ones that are known for being more performant (lower memory and CPU consumption, lower latency). And that’s when you’re draggi…

Rails was initially too slow for Github, so they forked it, didn't use "Rails" for a while [1], lost literal engineering years to upgrading it (same for Shopify), and now Github has an engineering department dedicated to working of the Rails master branch directly, which is huge engineering overhead and a problem and solution that shouldn't exist. Github co-founder Tom lamented using Rails at Github and has stopped using it [2].

If you're Github or Shopify and can throw (waste?) engineering years at solving a framework specific ecosystem nightmare problems, and have the klout and runway to hire core Ruby and Rails maintainers, then you're probably in a highly unique situation and could use any framework you want.

The rest of us don't see Rails as a great choice for Github. Doubt and questioning.

[1] https://videos.itrevolution.com/watch/550704376/ [2] https://youtu.be/GfhPeOiXDLA?t=725

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

#47

Post by byroot »

jacobsenscott wrote: post #20
nomilk wrote: post #5

Earlier quoted context omitted.

This is a particularly valid concern given ruby+rails seems quite memory inefficient to begin with. I've sometimes had smallish apps on 500mb heroku dynos crashing due to memory slowly climbing and eventually slowing things down as the dyno uses swap, and eventually 500mb of swap. IME ruby+rails doesn't seem to free up memory after it uses it, and that causes problems as the hours go by until the pod/dyno crashes or…

Ruby processes don't return the memory to the system,they reuse memory already allocated. This is for efficiency - allocating and freeing system memory isn't free. Even if it did, your peak memory usage would be the same. It doesn't allocate memory it doesn't need. If your memory usage doesn't plateau you have a memory leak which would be caused by a bug in your code or a dependency. But 500 to 1gb of memory required…

> Ruby processes don't return the memory to the system

That is not correct. Ruby do unmap pages when it has too many free pages, and it obviously call `free` on memory it allocated once it doesn't use it.

What happens sometime though is that because of fragmentation you have many free slots but no free whole pages. That is one of the reason why GC compaction was implemented, but it's not enabled by default.

But in most case I've seen, the memory bloat of Ruby applications was caused by glibc malloc, and the solution was either to set MALLOC_ARENA_MAX or to switch to jemalloc.

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

#48

Post by byroot »

diogenes4 wrote: post #31
jacobsenscott wrote: post #20

Earlier quoted context omitted.

Ruby processes don't return the memory to the system,they reuse memory already allocated. This is for efficiency - allocating and freeing system memory isn't free. Even if it did, your peak memory usage would be the same. It doesn't allocate memory it doesn't need. If your memory usage doesn't plateau you have a memory leak which would be caused by a bug in your code or a dependency. But 500 to 1gb of memory required…

> If your memory usage doesn't plateau you have a memory leak which would be caused by a bug in your code or a dependency. Extremely bold claim for a framework the size of ruby on rails. I would trot out my own evidence but the receipts are lost with time. Also—why isn't the allocation behavior tweakable at runtime? Seems pretty trivial with no downsides. It's not difficult to think of a scenario where a non-monotoni…

This person is incorrect, but even if they were correct, that wouldn't be a framework thing.

Memory management is handled by the language.

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

#49

Post by nindalf »

stevebmark wrote: post #46
nindalf wrote: post #37

Earlier quoted context omitted.

Rails was a great choice for Shopify, GitHub and Stripe, no doubt. No one is questioning that. GP’s sarcastic “rails doesn’t scale” implies that it would also be a great choice for people starting afresh in 2023. The reply asks for a comparison with other languages popular in 2023, especially ones that are known for being more performant (lower memory and CPU consumption, lower latency). And that’s when you’re draggi…

Rails was initially too slow for Github, so they forked it, didn't use "Rails" for a while [1], lost literal engineering years to upgrading it (same for Shopify), and now Github has an engineering department dedicated to working of the Rails master branch directly, which is huge engineering overhead and a problem and solution that shouldn't exist. Github co-founder Tom lamented using Rails at Github and has stopped u…

Yes, not ideal. But we can’t know what would have happened if they had chosen a different language in 2007. Did they have the option of an efficient, well supported language that continues to be used in 2023? Maybe Java, although Java languished for years before development picked up again. C# is also a candidate.

But one thing we can’t measure - how many candidates chose to join Shopify and GitHub because they were keen to work on Ruby? Java had a reputation for being boring, while Ruby was fun and exciting. Their success was possibly tied to this, but we’ll never know for sure.

In 2023 the calculus of what language to choose is different. But these companies are just glad they succeeded while others didn’t.

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

#50

Post by berkes »

wheels wrote: post #33
rapsey wrote: post #27

Time spent profiling and optimizing inherently inefficient technologies is an undervalued factor when deciding what stack to use.

Am I really going to have to get out the premature optimization quote? Most businesses fail. Those that don't fail, usually don't have interesting scaling issues. (You can go a really long way on a boring monolith stack.) So in most cases, whatever gets things out into the world and able to see if the business can be validated makes sense, and then you optimize later. A nonscalable stack that you can iterate on 50% f…

This hints at a false dichotomy. One that especially Ruby and Rails keep afloat.

Productivity and Scalability(in performance sense) aren't opposites.

Take Bash. Performs bad and is a guarantee for terrible productivity in a large category of software. But perfect for a niche. Take Java. Performs better than many, and allows for good productivity (if you avoid the enterprise architectures, but that goes for any language). Or take Rust. Productivity much higher than most C/C++ and in my case higher than with Ruby/Rails, and also much more performant.

Post reply on HN