But also on memory as well. There was a lot of improvements done on the Ruby garbage collector for 3.3, but there's still a lot of room for improvement, and a few fine folks at Shopify are looking into making the GC swappable so we'd be able to use mttk GCs with MRI.

As for the community caring about memory usage, I wonder how much of that has to do with the default Heroku dynos. Because it's an issue for small scale deployment. Once you scale more, you recoup a lot with CoW etc, so it's much less of a worry.

Matt's talk at latest Ruby Kaigi is a good intro: https://www.youtube.com/watch?v=chhNDhyPbyc

Oh wow. Had no idea there was no inlining. That is potentially another 2-3x performance.

    class NilClass
      def blank?
        true
      end

      def present?
        false
      end
    end

Matz very much sees Ruby as still a general purpose language that still supports scripting as a first tier concern. From that vantage bootup and memory are hugely important. Also providers like Heroku (I work there) charge for memory and the primary way to get parallelism with the GIL/GVL is using multiple processes where memory use can multiply rapidly (literally).

> speed up Ruby on Rails?

You can look at other communities to get a preview of what might come. Ruby now has “object shapes” like node.js which will benefit the community more once people start using it, enabling warnings and fixing hotspots where instance variables are not declared optimally.

Personally, I would like to see rails embrace the power of database backed constraints and fallback to using validation queries only when the database throws an error on commit. You can already saturate a CPU with processes and threads, the biggest bottleneck (IMHO) for most rails apps is still the database. Counterintuitively, pushing those constraints to the database can mean a net decrease in DB computing needed and more overall throughput.

Aside from that I think JIT will help do more with fewer resources. Which makes sense when the main YJIT sponsor has a huge server bill and being able to slash it in half more than justifies such long term gambles.

These check queries are individually fast but put a tremendous load on a running app’s database. If you halve the number of queries the database has to process you’ll see more resources to process the slow queries in addition to each commit being faster.

It ultimately depends on the read/write patterns of the app, but most non-trivial rails apps do a bunch of writing AND reading.

My suggestion is less a “this will change the world forever” and more a “fairly clear win, we just have to do it”.

In a prior life I talked Sgrif into implementing it before David caused them to drop Active Record maintenance work.

I know the broad strokes but don’t have the need or mandate to implement it, plus the active record internals are pretty gnarly. Tons of modules, very little encapsulation. Very hard to know the correct place to put stuff, so stuff goes wherever. It’s gotten better from some of the work of Yehudah, Aaron, and Sage but AFAIK there’s no one on core who wants to own it right now. Eileen has done a lot of work recently, but I don’t think it’s her primary focus.

Active Record is probably the "most owned" part of Rails, that's the one with the most core members and committers with deep knowledge of it.

As for your feature request, there's https://github.com/Shopify/activerecord-rescue_from_duplicat..., and we'd like to attempt to upstream that capability in Rails next year (but as everything it may or may not happen).

If that’s been a problem for you I totally believe you, and everything you say about a fix all makes sense.

Regarding JIT being faster, types are the next effective tool IMO.

The two drivers I see are:

- JIT has more stack frames to optimize away, allowing more optimization - you addressed this one

- JIT has more information to limit possible outcomes, therefore finding more opportunities

But uses 5-10x more memory.

Still has way more upside left to gain.

https://railsatscale.com/2023-11-07-yjit-is-the-most-memory-...

Can attest, just pulled TruffleRuby (both native and JVM), it is over ten seconds to start a hello world script cold. As in, script being run from command line as needed.

These are gains that are only going to make sense for the long-running process crowd.

[0] https://www.graalvm.org/latest/reference-manual/ruby/#aim

[1] https://www.graalvm.org/latest/reference-manual/ruby/Polyglo...

[2] https://medium.com/graalvm/graalvm-ten-things-12d9111f307d

Just curious, how well do we know this, e.g., theory, experiments, it's being done, or ?

It'd be fun if RiiR[uby] were a small part of the overall memory saftey glacier (e.g., https://www.cisa.gov/case-memory-safe-roadmaps)