I’m still surprised that we haven’t seen much larger improvements in Ruby performance over the last decade given the large number of major tech companies using Rails.
Yes, I'm aware of 3x3 but for the most common usage of Ruby which if for Rails apps - there hasn't been anything like the gains PHP saw from 5.x to 7.x.
Especially from Microsoft, who has deep compiler/language expertise, and who owns GitHub (large Rails app).
>> Yes, I'm aware of 3x3 but for the most common usage of Ruby which if for Rails apps - there hasn't been anything like the gains PHP saw from 5.x to 7.x.
This has simply not been my experience. The jump in performance in the 3.n has been awesome, to the point were I even downgraded / removed servers.
Ironically the greatest speed (and memory) improvements have been in the swapping out the supporting JS ecosystem components that Rails uses, for example swapping Webpack for the Go based Esbuild.
Not following what you mean. This server is from a shopify employer (major enough?). This server makes quite impressive improvements in terms of memory usage. Moreover, shopify is contributing a production grade JIT to the CRuby runtime.
Howdy, I'm on the Shopify team that is working on both pitchfork and a few different performance-improvement projects for Ruby. There's a ton of activity around Ruby performance right now!
I think we're entering a period of increased experimentation and rapid evolution as demonstrated by projects like YJIT[1][2], improved inline caching[3][4] and Object Shapes[5] (also used by V8), and variable-width allocation[6][7], and smaller improvements like better constant invalidation[8]. Significant investments in TruffleRuby[9] are still going on by Oracle, Shopify, and other companies.
And recently, Takashi Kokubun gave a talk at Ruby Kaigi about the future of JIT compilers in Ruby that gives a peek at a whole new set of optimizations Ruby can work on (as well as some performance comparisons against other interpreted languages)[10]. You may be surprised to see how well Ruby (with the JIT enabled) performs compared to Python 3.
All of which is to say, I think there's quite a bit of performance improvement being made in recent Rubies, and that trend will likely continue for quite some time.
update And I forgot to mention that some very notable computer science researchers and their teams are working in the Ruby community now![11]
Could you comment on any projects within Shopify that are helping Ruby's concurrency story? I'm aware of Ractors (https://docs.ruby-lang.org/en/master/ractor_md.html) and Fibers, but it's unclear to how feasible these primitives currently are to build the necessary abstractions on top of them that would make Rails more concurrent.
https://github.com/socketry/falcon is an interesting project, but again, it's not clear how difficult it would be deploying a Rails app on top of this. My experience with these concurrency models in Rails apps is that one single gem could make a blocking IO call (for example) and negate all of the concurrency/performance gains. It would be cool if Ruby could be configured to throw errors for these types of calls to make finding and fixing offending gems easier.
There's a lot of really great projects happening and plenty to be hopeful about, but when that stuff will land or the changes the rest of the community and ecosystem should think about making still isn't clear.
To be honest, Shopify isn’t particularly invested in Ruby concurrency.
That’s not really a use case we have, and the community is already investing a lot in that direction (ioquatix with fiber scheduler and ko1 with N:M threads and Ractors)
Which part of raw web performance? These don't seem like web performance benchmarks. IOW I'm not sure how calculating digits of PI impacts serving HTML.
Seems like we need benchmarks for actual web workloads. :)
There have been plenty of major performance improvements for Ruby but most of them require changes that just aren't feasible for a large codebase. For example, there are alternative Ruby interpreters that are far faster than the MRI but they're not usually a drop in replacement because they don't have full Gem or really general ecosystem compatibility.
Also, some performance improvements like JIT just don't matter that much for Rails because the primary problem isn't single thread performance it's the lack of cheap parallelism.
>Especially from Microsoft, who has deep compiler/language expertise, and who owns GitHub (large Rails app).
I thought it was missed opportunities those working inside GitHub could not persuade Microsoft to at least budget out additional resources for Ruby. Although they might have their own battle trying to keep everything Rails and not moving to .NET
It does worry me a bit that all resources are coming from Shopify, hopefully they can keep growing so resources isn't a problem in the near future.
You are making multiple comments talking about Microsoft and Shopify not putting resources into Ruby/rails but both companies have core contributors on them.
Where did I said Shopify not putting resources when the last part of my comment was exactly about Shopify putting resources into Ruby Rails.
Microsoft have contribution into Ruby? Or Do you meant Github has Core Contributor in Rails? Name me a single Microsoft employees actively helping in Ruby Core.
> I’m still surprised that we haven’t seen much larger improvements in Ruby performance over the last decade given the large number of major tech companies using Rails.
Every place I've worked in the last ~5 years has treated Ruby as "legacy" code for better or worse.
Yes, I'm aware of 3x3 but for the most common usage of Ruby which if for Rails apps - there hasn't been anything like the gains PHP saw from 5.x to 7.x.
Especially from Microsoft, who has deep compiler/language expertise, and who owns GitHub (large Rails app).