Project

General

Profile

Actions

Feature #17684

closed

Remove `--disable-gems` from release version of Ruby

Added by hsbt (Hiroshi SHIBATA) 6 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:102797]

Description

In my understand, --disable-gems is only debugging feature for ruby-core team.

But some users enabled its option in test environment for performance or etc. So, --disable-gems option is wrong usage for some users.

We should remove it from package version of ruby.

Updated by chrisseaton (Chris Seaton) 6 months ago

How should people who were using it for performance migrate off the option?

Updated by naruse (Yui NARUSE) 6 months ago

Agreed. Unfortunately this increases the cost of development to support --disable-gems.
In other words, this feature breaks the assumption that every Ruby has RubyGems.
This feature should be removed.

Updated by naruse (Yui NARUSE) 6 months ago

chrisseaton (Chris Seaton) wrote in #note-1:

How should people who were using it for performance migrate off the option?

--disable-gems should be just ignored in the future version, and the performance will be degraded.

Updated by chrisseaton (Chris Seaton) 6 months ago

I don't have anything invested in this myself, but just for information to help the discussion, here's two examples of apps that use the option

Updated by xtkoba (Tee KOBAYASHI) 6 months ago

Will we be able to re-enable the --disable-gems option when we build ruby from source code? I think it is useful for narrowing problems down. For that purpose it might be sufficient that miniruby does not depend on Gems, though.

For performance we can use mruby (https://github.com/mruby/mruby) after all.

Updated by vo.x (Vit Ondruch) 6 months ago

I'd love to see this clarified. IMO, there should be other ways to manage $LOAD_PATH then RubyGems. For such use cases, this option is useful IMO.

Updated by deivid (David Rodríguez) 6 months ago

I disagree on removing this option, I don't think the benefits of removing it are strong enough, even if it didn't make any difference in performance.

Actions #8

Updated by hsbt (Hiroshi SHIBATA) 6 months ago

  • Description updated (diff)

Updated by NuriYuri (Youri Nouri) 6 months ago

I'm also using the --disable-gems option. I make games on Ruby but I'm not using gems and since the main audience is Windows, I have to distribute portable Ruby version that HAS to work on any path (including those with accents). I noticed that the rubygems are causing a lot of issues when the game needs to load native extensions (FMOD, SFML, sockets...) so I disable the gems and if they're needed, we include them explicitely using the require 'rubygems' command.

I would suggest that people who needs gems require rubygems manually or that ruby load rubygems automatically only if the script has a Gemfile (I bet this might already be handled by bundler & the bundle exec command).

Updated by Eregon (Benoit Daloze) 6 months ago

I think --disable-gems is also useful to investigate issues, e.g. RubyGems used to override Kernel#warn (fixed in Ruby 3).
It can significantly simplify investigating issues with require.
I agree it's not very common to need it for debugging, but it turned up useful a couple times.
If it's not available for releases then it becomes inconvenient to investigate such cases.

Also the impact on startup time is still significant, so for very short scripts it can be noticeable (especially if calling out to subprocesses or running many small scripts).
That's something that can potentially be improved in CRuby and/or RubyGems.
For instance by loading RubyGems lazily (autoload :Gem, try loading rubygems the first time require fails), which TruffleRuby does.

Finally, I guess for JITs it's quite useful to limit the amount of Ruby code loaded and run on startup, so having --disable-gems to investigate JIT issues seems useful.
If it only works on development builds, then again it's inconvenient to investigate a bug report from a user using a release.

Updated by tenderlovemaking (Aaron Patterson) 6 months ago

I like using --disable-gems for scripts that need to be fast. For example, I call ruby from Vim to get some information about the Ruby environment:

" Add stdlib of environment's ruby to path
let g:stdlib = system('ruby --disable-gems -rrbconfig -e"print RbConfig::CONFIG[\"rubylibdir\"]"')
let &path .= "," . stdlib
let g:ruby_path = &path

Adding 60ms (or more) for these "fast commands" would be pretty annoying.

[aaron@tc-lan-adapter ~]$ time ruby --disable-gems -rrbconfig -e"print RbConfig::CONFIG[\"rubylibdir\"]"
/Users/aaron/.rubies/ruby-trunk/lib/ruby/3.1.0
________________________________________________________
Executed in   20.60 millis    fish           external 
   usr time   12.12 millis  146.00 micros   11.98 millis 
   sys time    6.33 millis  741.00 micros    5.59 millis 

[aaron@tc-lan-adapter ~]$ time ruby -rrbconfig -e"print RbConfig::CONFIG[\"rubylibdir\"]"
/Users/aaron/.rubies/ruby-trunk/lib/ruby/3.1.0
________________________________________________________
Executed in   79.02 millis    fish           external 
   usr time   61.54 millis  115.00 micros   61.43 millis 
   sys time   14.46 millis  679.00 micros   13.78 millis 

Updated by lugray (Lisa Ugray) 6 months ago

I also have a use case where I use --disable-gems for performance. I maintain a tool that provides some shell hooks in ruby, and any slow down in getting to a prompt is incredibly noticeable.

Updated by Eregon (Benoit Daloze) 6 months ago

Another use case: Bundler's --standalone mode knows all gem directories and doesn't need to load either RubyGems or Bundler, which can save quite some time on application startup.
It seems a shame if it would still load RubyGems needlessly due to removing --disable-gems.

Updated by tenderlovemaking (Aaron Patterson) 6 months ago

I forgot another place I use --disable-gems. I think RubyGems does lots of IO at startup, and IO is extremely slow on my Raspberry PI. I'm using Ruby on Raspberry PI for some IoT stuff around my house and I use --disable-gems in those environments. Here is the difference:

pi@lcd-screen:~ $ time ruby -v --disable-gems -e' '
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [armv6l-linux-eabihf]

real    0m0.291s
user    0m0.118s
sys 0m0.082s
pi@lcd-screen:~ $ time ruby -v -e' '
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [armv6l-linux-eabihf]

real    0m2.395s
user    0m1.998s
sys 0m0.129s

My Ruby installation only has the default gems installed, but RubyGems adds 2 seconds to startup.

Updated by shyouhei (Shyouhei Urabe) 6 months ago

My gut feeling is that it's miserable for people to confuse --disable-gems as a zero-cost speed boost option. Maybe rubygems is too slow now.

Actions #16

Updated by naruse (Yui NARUSE) 6 months ago

  • Status changed from Open to Closed

Applied in changeset git|d58daad37bd5fd09c7ff74be17074fc51faac8d3.


[Feature #17684] Declare --disable-gems is for debugging

Updated by naruse (Yui NARUSE) 6 months ago

At this time we just update --help.
The conclusion of ruby core's discussion is

  • As the first step, let’s update the --help to explicitly state that --disable-gems is just for debugging
  • If rubygems startup becomes so fast in future, we can consider removal of --disable-gems (but still it is desirable for debugging)
  • Or someone who happen to report about --disable-gems again, we will consider again.

We also discuss RubyGem accesses too many files in startup. We expect gem team improve that.
https://gist.github.com/ko1/f0d8c899d580f7f69bb5608ab6d8215f

Actions

Also available in: Atom PDF