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

Ruby 3.3's YJIT: Faster While Using Less Memory

railsatscale.com

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#11

Post by jweir »

avg_dev wrote: post #9

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…

Since Ruby 3 I would recommend trying again. It is much faster now.

Back in the Ruby 2 days we had tools like Zeus to preload our development application because loading was so slow (10-20 seconds). These days we just load the whole app (2 seconds)

These benchmarks show a 2x speed up. While I haven't see that, I have seen at least a 50% increase in performance for our applications.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#12

Post by ecshafer »

avg_dev wrote: post #9

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…

I work at Shopify (not the team that does YJIT) so I am working on a very large, modern Rails codebase. (my opinions are my own)

I think rails code is the easiest code to follow in any code base that I have ever worked on. The enforcement in the framework of the code structure, models containing the object and schema relationships, focus on message passing, skinny controllers. Its very very easy to debug rails code and work in code that is relatively foreign due to the consistency across the code base. Some of this might be discipline at Shopify, I do think we have a very good code review culture. But I have been places that rest controllers just led to a spaghetti of "Operations" and "Processors" that just change state everywhere and a bunch of microservice network calls.

Ruby speed hasn't been an issue. We focus on latency and speed quite a bit and work on keeping request times low. The speed of ruby running is a good trade off for the speed of development I think. And most slow running requests really seem to end up due to network io or database calls that I see.

Sorbet uses a kind of type annotation, its very ugly and I do not like it. I really would prefer something more built into the language. Like def foo(Integer x) -> Integer. The big issue is method arguments I think since Ruby already uses :x, x:, x =, and a lot of the other symbols that indicate types so its hard to add it in an optional fashion.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#13

Post by adamors »

apstats wrote: post #2

I moved from ruby 2.7 to 3.2 for a rails app and was hopeful that it would lead to large speedups like shopify claims it did for them, but was bummed to find it did basically nothing. Anyone else running a large rails app have a similar or different experience?

I benchmarked a good sized app (ran a black-box QA suite multiple times) while monitoring performance and req/response times with Prometheus/Grafana with Ruby 3.2.

With YJIT enabled memory usage ballooned and performance dipped below non-YJIT Ruby 3.2, IIRC the difference was a good 10% degradation. Granted, it's an API only service so no HTML is being generated, only JSON and that could be the culprit.

Suffice it to say, we didn't enable YJIT for 3.2. Maybe 3.3 is indeed different, but both the faster and less memory claims are really suspicious to me.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#14

Post by graypegg »

ecshafer wrote: post #12
avg_dev wrote: post #9

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…

I work at Shopify (not the team that does YJIT) so I am working on a very large, modern Rails codebase. (my opinions are my own) I think rails code is the easiest code to follow in any code base that I have ever worked on. The enforcement in the framework of the code structure, models containing the object and schema relationships, focus on message passing, skinny controllers. Its very very easy to debug rails code a…

Just curious, what's your opinion on YARD comments for typing? I have a little more experience with that, than I do Sorbet (or RBS as well) and I found it to be at least tolerable. Though something like your `-> Integer` would be amazing though if there was somehow a way to make it work with the syntax of Ruby.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#15

Post by adamors »

mortallywounded wrote: post #7

I get the need to improve Ruby's speed and memory usage, but there's much to be desired. I really enjoy Rails and Ruby in general, but the performance is terrible. I'd like to see how Ruby 3.3 stacks up to other languages and runtimes.

In 2023 if performance is a functional requirement, Ruby is still not the answer IMO. For companies like Shopify, there's really no other alternative at this point, but their "fast" is only fast compared to the performance they've had 1-2 years ago.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#16

Post by ecshafer »

graypegg wrote: post #14
ecshafer wrote: post #12

Earlier quoted context omitted.

I work at Shopify (not the team that does YJIT) so I am working on a very large, modern Rails codebase. (my opinions are my own) I think rails code is the easiest code to follow in any code base that I have ever worked on. The enforcement in the framework of the code structure, models containing the object and schema relationships, focus on message passing, skinny controllers. Its very very easy to debug rails code a…

Just curious, what's your opinion on YARD comments for typing? I have a little more experience with that, than I do Sorbet (or RBS as well) and I found it to be at least tolerable. Though something like your `-> Integer` would be amazing though if there was somehow a way to make it work with the syntax of Ruby.

The RBS syntax I like, I don't like how its a separate file though. I haven't used YARD but I think it would have similar issues to Sorbet. I much prefer things to be inline in programming languages in general. YARD looking at it, makes me think of Javadoc, which I always saw the issue with it being that it drifted from implementation over time as people don't update it. Sorbet does enforce it to be updated, and will throw an exception so your build will fail. Does YARD do that?

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#17

Post by why-el »

avg_dev wrote: post #9

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…

In my experience most Ruby apps (Rails in particular) develop this idea that Ruby is the bottleneck when in reality most of the time it's something else entirely (mostly DB or network IO). Of course you found compiled languages faster! that's by definition. You also tried Ruby on CPU sensitive code bases ("Advent of Code or Project Euler solutions"), that's textbook "ruby is slower than C". Rails pays dividends in the web and in large code bases with many engineers.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#19

Post by ksec »

My question is what's next? Without sacrificing (much) memory. We know from TruffleRuby that given enough warmups and lots of memory it could be multiple times faster than CRuby. And compared to Ruby 3.3 YJIT may be 2-3x faster. But it seems the communities as a whole cares a lot about memory usage.

We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. But other than that do we have anything on the table that will significantly speed up Ruby Rails?

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#20

Post by jbverschoor »

avg_dev wrote: post #9

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…

Try Crystal if that's a concern https://crystal-lang.org/
Post reply on HN