Yes, my thought here is booting itself is "useless", one always wants to do something with the booted app, which will load more modules/classes and so will amortize any extra loading done before to some degree.

IOW the change sounds to me like a nice simplification which seems cleaner and e.g. worth it to avoid redefining require. The 10% overhead doesn't sound ideal, but I wonder how much overhead would actually be felt by Zeitwerk users (i.e. just booting is not useful, one always wants to do something).

Of course, but what I meant by small test is not the app being big/small but the test testing e.g. a single model/controller and not loading the whole app. I think as soon as a model/controller is loaded, a bunch more gets loaded, and any extra "eager loading" (as in your change) is less visible.

What if you timed running a single small test? I would guess much less difference there.
Similarly for the dev case, one idea would be to time process-start to first-request handled.
Then if the difference is minimal there it's probably hardly visible to the user.

How did you measure the increase for dev/test? I'd expect for those the time from start-the-process to something-useful changes less because they will both load some parts of the app at least.

Typo fix: always removing empty **kw on the caller* side

That looks pretty wild, is the logic ported from CRuby?
In TruffleRuby it's a lot simpler, partly due to some intentional simplifications like always removing empty **kw on the callee side, always dup kw and let escape analysis deal with it, and pass kwargs in calling convention as last argument

I suspect it's done like that for extra safety but one can also just run `sudo dnf upgrade` while running the system and it works fine.
I don't like apt because it's so much slower to install packages, last case I saw is building a Docker image, > 2 minutes to install 7 packages with apt.

That page takes a while to load with all the iframes though so I'd actually prefer to link to RubyEvents if all talks are there, but that's not reasonable since there are also talks at non-Ruby conferences. Could do a mixed approach with linking to RubyEvents and list the few extra talks directly.

Let me know if I can make a PR about that/to which file or so. If we want to be extensive I recently went through all RubyKaigi+RubyConf talks about TruffleRuby to make truffleruby.dev/talks

Not a request and feel free to do nothing about it, but I noticed some talks from Chris notably www.rubyevents.org/talks/deopti... and www.rubyevents.org/talks/ruby-s... are not included in the TruffleRuby page. Which kind of makes sense since it was called JRuby+Truffle back then 😅

May I suggest including bsky.app/profile/truf..., maybe in the next edition?

Yeah that's pretty shady behavior, seems worth reporting. I usually leave a comment to let people know the spam they are causing in such cases. Pretty weird to copy issues like that.

Not entirely sure because I haven't tried in a while but worth a shot. It might also depend on which parts you use so I'd suggest to try it and see.

@statitudes.com Maybe you could try running the full benchmark or even the full app on TruffleRuby?

I ran your benchmarks from bugs.ruby-lang.org/issues/21824 on TruffleRuby with a slight tweak to use benchmark-ips for warmup and the result is 2.42x faster than CRuby 3.4.8 on the first benchmark and 4.66x faster on the second/minimal benchmark!
See gist.github.com/eregon/e3692... for details.