[#107430] [Ruby master Feature#18566] Merge `io-wait` gem into core IO — "byroot (Jean Boussier)" <noreply@...>

Issue #18566 has been reported by byroot (Jean Boussier).

22 messages 2022/02/02

[#107434] [Ruby master Bug#18567] Depending on default gems when not needed considered harmful — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18567 has been reported by Eregon (Benoit Daloze).

31 messages 2022/02/02

[#107443] [Ruby master Feature#18568] Explore lazy RubyGems boot to reduce need for --disable-gems — "headius (Charles Nutter)" <noreply@...>

Issue #18568 has been reported by headius (Charles Nutter).

13 messages 2022/02/02

[#107481] [Ruby master Feature#18571] Removed the bundled sources from release package after Ruby 3.2 — "hsbt (Hiroshi SHIBATA)" <noreply@...>

Issue #18571 has been reported by hsbt (Hiroshi SHIBATA).

9 messages 2022/02/04

[#107490] [Ruby master Bug#18572] Performance regression when invoking refined methods — "palkan (Vladimir Dementyev)" <noreply@...>

Issue #18572 has been reported by palkan (Vladimir Dementyev).

12 messages 2022/02/05

[#107514] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY` — "byroot (Jean Boussier)" <noreply@...>

Issue #18576 has been reported by byroot (Jean Boussier).

47 messages 2022/02/08

[#107536] [Ruby master Feature#18579] Concatenation of ASCII-8BIT strings shouldn't behave differently depending on string contents — "tenderlovemaking (Aaron Patterson)" <noreply@...>

Issue #18579 has been reported by tenderlovemaking (Aaron Patterson).

11 messages 2022/02/09

[#107547] [Ruby master Bug#18580] Range#include? inconsistency for String ranges — "zverok (Victor Shepelev)" <noreply@...>

Issue #18580 has been reported by zverok (Victor Shepelev).

10 messages 2022/02/10

[#107603] [Ruby master Feature#18589] Finer-grained constant invalidation — "kddeisz (Kevin Newton)" <noreply@...>

Issue #18589 has been reported by kddeisz (Kevin Newton).

17 messages 2022/02/16

[#107624] [Ruby master Bug#18590] String#downcase and CAPITAL LETTER I WITH DOT ABOVE — "andrykonchin (Andrew Konchin)" <noreply@...>

Issue #18590 has been reported by andrykonchin (Andrew Konchin).

13 messages 2022/02/17

[#107651] [Ruby master Misc#18591] DevMeeting-2022-03-17 — "mame (Yusuke Endoh)" <noreply@...>

Issue #18591 has been reported by mame (Yusuke Endoh).

11 messages 2022/02/18

[#107682] [Ruby master Feature#18595] Alias `String#-@` as `String#dedup` — "byroot (Jean Boussier)" <noreply@...>

Issue #18595 has been reported by byroot (Jean Boussier).

15 messages 2022/02/21

[#107699] [Ruby master Feature#18597] Strings need a named method like `dup` that doesn't duplicate if receiver is mutable — "danh337 (Dan H)" <noreply@...>

Issue #18597 has been reported by danh337 (Dan H).

18 messages 2022/02/21

[ruby-core:107471] [Ruby master Feature#18568] Explore lazy RubyGems boot to reduce need for --disable-gems

From: "headius (Charles Nutter)" <noreply@...>
Date: 2022-02-03 16:17:50 UTC
List: ruby-core #107471
Issue #18568 has been updated by headius (Charles Nutter).


> I think a faster boot time while still having RubyGems enabled by default would be good for all Rubies.

Thank you for providing those links... I knew I had seen that code but could not remember where it was located.

Making these changes in RubyGems would be great, if that is sufficient to reduce boot times. I was not clear on how much of this could live there versus how much needs to be changed in the Ruby boot process.

One thing that has always bothered me about RubyGems is its constant rescanning of gemspecs and lib directories from gems which I think we all agree should NEVER BE MODIFIED. There's no good reason not to build up a local file index, a la [gel](https://github.com/gel-rb/gel). At worst, a `gem reindex` command that rescans all installed gemspecs and libs would be sufficient to support the very few dev-time cases for adding or removing files from an installed gem.

> I worked on https://github.com/rubygems/rubygems/pull/4199 a while ago

This approach looks similar in spirit to `gel` in that it creates an index of each gem's contents. A single index might be even faster but would require different strategies to maintain it. The advantage of a single index would of course be a single file read, and potentially that file produces exactly the structure we need to quickly find requirable files.

I'm excited to see this moving forward. On @tenderlove's recommendation I am adding a note to the next dev meeting.

----------------------------------------
Feature #18568: Explore lazy RubyGems boot to reduce need for --disable-gems
https://bugs.ruby-lang.org/issues/18568#change-96374

* 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread