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

31–40 of 158 posts

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

#31

Post by diogenes4 »

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…

> 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-monotonically-increasing-heap-size is desirable.

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

#32

Post by rapsey »

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.

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.

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

#33

Post by wheels »

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% faster is more likely to produce a viable company than a more scalable stack that's slower to work with.

If you're a hired employee, it's easy to forget that the place you're working for is already a big exception just by the virtue of it grew large enough to hire you.

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

#34

Post by rognjen »

Scarbutt wrote: post #19
sho wrote: post #2

> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"

Are there companies in the last 7 years that have started with rails and have become big like spotify?

(I assume you mean Shopify not Spotify)

No exactly a fair question because Shopify is much older and is valued at 70B. For a company to have done it in half the time would have been impressive regardless of tech whereas on average it takes 7 years to become a unicorn.

I do know that Aircall is relatively young, on a good trajectory and runs Rails.

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

#35

Post by netheril96 »

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.

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

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

#36

Post by pmontra »

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

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

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

#37

Post by nindalf »

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.

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 dragging the conversation back to 2006. It’s not 2006 anymore.

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

#38

Post by winrid »

rapsey wrote: post #27

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

They used this stack because it was productive for them.

They don't need to do any of this. The product is fast enough. They make money. It's purely to fatten the bottom line.

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

#39

Post by cyclotron3k »

rapsey wrote: post #32
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.

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

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

#40

Post by [deleted] »

Gigachad wrote: post #15
CaveTech wrote: post #9

Earlier quoted context omitted.

These two points are entirely unrelated. Scaleability in that meme is not considering horizontal scalability, which approaches infinity for literally any language/framework. It only makes sense in the context of vertical scalability, and gross req/sec offers no insight into whether or not that's true.

I can't see how vertical scalability even matters for rails You can just start more instances. It's not like two active web requests need to interact with each other.

[deleted]
Post reply on HN