Jean Boussier

As discussed on campfire, it's debatable whether it's a good default or not. Every time a major GC triggers past the boot sequence, is in my opinion a Ruby GC...

> What drawbacks do you see with running GC OOB Throughput impact. While the process is running GC, it's not accepting and processing requests. It's even worse with Puma with...

> One just idea is I was thinking the same. I guess I need to write the feature request :) (FYI @peterzhu2118) > On multi-thread (puma-based?) web application it does...

Thinking more about it, this should also prevent object promotion, otherwise it may make the issue worse. On paper, once boot is done, no object should ever survive a request...

> offer a OOB GC default Again, OOB GC is a hard tradeoff that I'm not quite confident to default on users, it's really something you need to know is...

We discussed this at a recent Shopify ruby-infra gathering and will try to get the feature described in https://github.com/rails/rails/issues/50449#issuecomment-1870688614 in Ruby 3.4. One slight note though is that we believe...

FYI: https://bugs.ruby-lang.org/issues/20443

> This cuts ~10s from the test run of HEY when run by 24 processes against the 178 tables, since ~4,000 table truncates can then be skipped. Are these 24...

Not sure if we really want to change this. In your case I believe you can easily fix this with: ```ruby has_many :posts, inverse_of: :user, foreign_key: :person_id ```

I'd say ideally it should be fixed, but I fear this may break apps, and I'm not convinced this is a big enough problem to take that risk. If you...