Issue #21951 has been updated by hsbt (Hiroshi SHIBATA). Some libraries implicitly depend on `did_you_mean` and other gems being loaded at boot, calling their class methods (e.g., `DidYouMean::SpellChecker`) without an explicit `require`. I tried to switch from a simple deferred `require` approach to using `autoload`. Unfortunately, when using `autoload` for lazy loading of them, some Ractor btests is failed with YJIT/ZJIT. * https://github.com/ruby/ruby/actions/runs/23230199826/job/67521873278?pr=163... * https://github.com/ruby/ruby/actions/runs/23230199813/job/67521873227?pr=163... Does anyone know that causes? ---------------------------------------- Feature #21951: Lazy load error extension gems to speed up boot time https://bugs.ruby-lang.org/issues/21951#change-116769 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/