From: "Eregon (Benoit Daloze)" Date: 2022-02-03T12:48:55+00:00 Subject: [ruby-core:107464] [Ruby master Feature#18568] Explore lazy RubyGems boot to reduce need for --disable-gems Issue #18568 has been updated by Eregon (Benoit Daloze). I think a faster boot time while still having RubyGems enabled by default would be good for all Rubies. https://github.com/oracle/truffleruby/blob/14ec2c2673188d47374a0570cf036864fcafe0b3/src/main/ruby/truffleruby/core/truffle/gem_util.rb is most of the logic for handling upgraded default gems. And there is some logic directly in `require` and `require_relative` to handle upgraded default gems: https://github.com/oracle/truffleruby/blob/14ec2c2673188d47374a0570cf036864fcafe0b3/src/main/ruby/truffleruby/core/kernel.rb#L246-L254 I wonder how much of this could actually move to RubyGems. Maybe RubyGems could be much more lazy and do something similar? That would probably make more sense as an issue on the RubyGems tracker though. In Ruby 3.1.0, RubyGems loads 23 (rather big) Ruby files (4401 SLOC) + rbconfig and monitor (stringio, uri no longer, that was in 2.6). In addition it also reads all default gem gemspecs, which might take a long time, and is more Ruby code loaded: https://gist.github.com/eregon/5318509127d36e74dc5d555903760215 That's a lot, in comparison lazy rubygems loads 1 small Ruby file (158 SLOC), does not load any gemspecs, and it just checks if some paths exist for default gems in `require`. To achieve that it's probably necessary to not define `Gem` early on and let that be an autoload. So we would need another namespace module for the lazy-rubygems logic. cc @deivid ---------------------------------------- Feature #18568: Explore lazy RubyGems boot to reduce need for --disable-gems https://bugs.ruby-lang.org/issues/18568#change-96367 * Author: headius (Charles Nutter) * Status: Open * Priority: Normal ---------------------------------------- In https://bugs.ruby-lang.org/issues/17684 there was debate about whether the `--disable-gems` flag should be removed. Several folks were in favor, since Ruby without RubyGems is fairly limited, but others wanted to keep the flag for small, fast command line scripts that do not depend on RubyGems. Lazily loading RubyGems might be a middle ground, and it has been explored in some depth by TruffleRuby: https://github.com/oracle/truffleruby/blob/master/src/main/ruby/truffleruby/core/lazy_rubygems.rb @eregon shows how this improves their startup time in this article from a couple years ago: https://eregon.me/blog/2019/04/24/how-truffleruby-startup-became-faster-than-mri.html I believe this approach has merit and could be beneficial to both CRuby and JRuby if we can collaborate on how the lazy loading should happen and figuring out where the edges are. @eregon may know some of those edges if they have run into them in TruffleRuby. A simple test of `--disable-gems` on CRuby 3.1 shows what an impact it has, which we might be able to duplicate in a lazy boot WITHOUT losing RubyGems functionality and default gem upgrading: ``` $ time ruby -e 1 real 0m0.107s user 0m0.068s sys 0m0.030s $ time ruby --disable-gems -e 1 real 0m0.019s user 0m0.007s sys 0m0.008s ``` Over 80% of CRuby's base startup is due to eagerly booting RubyGems. We can do better! -- https://bugs.ruby-lang.org/ Unsubscribe: