[ciconia]

Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. In any case, it's still early to determine the impact on performance from upgrading to Ruby 3.3. I guess we'll be able to tell more in the coming months.

[pdimitar]

> Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime.

Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.

[ajmurmann]

How much of the time in a given request is even spent in Ruby code? The majority of web apps that were slow and I got a chance to analyze were spending much of the time in DB queries and slowness was usually due to unoptimized DB queries. Even endpoints that were fast, still spent a large percentage of their time not in Ruby but in DB and service requests

[pdimitar]

That is true, yes, but still comparing e.g. Rust vs. Ruby I'd think Rust spends anywhere from 10ns to 100ns (outside of waiting on DB) and Ruby no less than 10 ms. Still pretty significant and can add up during times of big load.

Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.

[ajmurmann]

My point was that if we look at Rails performance going up 10%, what does that mean for time spent in Ruby. I'd believe anything from a 15% to a 80% reduction of time spent in Ruby code

[pdimitar]

I haven't seen 80% anywhere in the linked article[0] so let's use facts and not beliefs.

It is possible Ruby itself got accelerated a lot, okay, I am just not sure that's relevant since almost all Ruby usage is Rails.

[0] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

[ajmurmann]

I wasn't trying to say that Ruby indeed is 80% faster, but that it's pretty much impossible to drive actual Ruby speed up from Rails numbers, since we don't know nearly enough about the Rails app

[Alifatisk]

It is relevant if the cause of the slowness is due to the framework rather than the language itself.

The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead.

Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.

[resonious]

I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.

[Alifatisk]

Absolutely, I should maybe clarify that I did not mean to say that we can fully rule out the language itself as a cause of the poor performance, Ruby always perform worse than Go in this example for obvious reasons.

But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.

[pdimitar]

> But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion!

I did not claim that in general sense, I said it with the context that even if Ruby got accelerated a lot then that's still kind of inconsequential because most Ruby usage is Rails.

[Alifatisk]

Oh okey, that clarifies it!

[cutler]

Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.

[resonious]

If we're comparing "programming languages that can be used to make websites" then it's totally apples to apples. Ruby and Go (and Rust, Java, etc) are all valid options and so I think it's smart to compare them before starting a web project.

[csjh]

Isn’t factoring out C based libraries ignoring a large part of the Python ecosystem?

[Lio]

It's not that you should factor them out but if C is actually doing the work you can call the same excellent libraries from Ruby too.

e.g. Numo for NumPy or Ruby-Polars for python polars.

[Alifatisk]

I haven’t used Python in years but from what I’ve understood by reading other comments, factoring out C-based libraries would rule out a large portion of what makes Python so popular. Especially on the scientific side.

So I think you’re right.

[pdimitar]

How is a C codebase a part of the Python ecosystem?

More accurate statement would be: Python is piggy-backing on hugely successful C libraries and claims big performance on their backs, IMO.

[cutler]

Yes, but if you're comparing language performance that's important.