Here is the pull request...
Enable Puma's nakayoshi_fork feature #11121
What type of PR is this? (check all applicable)
- [ ] Refactor
- [ ] Feature
- [ ] Bug Fix
- [x] Optimization
- [ ] Documentation Update
Description
Here are a few posts about GC.compact
in Rails....
- https://dev.to/palkan_tula/cables-profiling-returns-gc-compact-jemalloc-33c9
- https://engineering.appfolio.com/appfolio-engineering/2019/3/22/ruby-27-and-the-compacting-garbage-collector
- https://www.infoworld.com/article/3404481/ruby-27-improves-garbage-collection-pattern-matching.html
My thoughts here are that if tests pass, this is something we could deploy and observe. There may be more ways we could use this in specific cases.
Puma's current experimental nakayoshi_fork
configuration essentially does this...
4.times { GC.start }
GC.compact # if available
GC.compact
is a newer Ruby operation, and you can read a lot more about it in some of the linked resources in the PR.
The outcome in our app was... maybe 2% memory reduction in 24 hours of observation. It's hard to tell if this is actually 2% or just random variance.
2% is not much to write home about, but it's also not nothing. So for one line of code, it's probably worth it, however there are definitely bigger gains to be had elsewhere
Top comments (1)
Optimization is hard to sniff out for sure! Keep up the profiling and something will definitely stand out.
Or it's something that's low impact but run way too many times. 😄