thedarkone

Mine current hunch is that you are running into an issue with `Module#name` (note that `_mod_name` is a pure method alias for native `Method#name`) being 2 to 3 orders of...

Don't know what to do about that abysmal anon module/class `mod.name` performance on MRI. For example with my app I have 4009 non-anonymous modules/classes and calling `.name` on all of...

> Is keeping a persistent set/hash of anon class to skip the _mod_name look up a good solution? I can't, they wouldn't get garbage collected by Ruby VM then... I...

> What I'm wondering is how does languages like Python handles anon name look ups. This is purely an MRI implementation problem, other Ruby VMs (JRuby and Rubinius) don't suffer...

@pxue not sure if `rails-dev-boost` is ever going to attempt to fix your problem, but there is hope on the MRI front! https://bugs.ruby-lang.org/issues/11119

Hey @frobichaud, thanks for reporting this. I'm reasonably certain your issue stems from Rails routes keeping a reference to a now stale `BaseApi`/`V1::NotificationApi`. In short, the problem is that `rails-dev-boost`...

ping @frobichaud, any chance you had a look at this?

I'll think about monkey-patching i18n reloader into the async module. I had multiple reports of Sprockets somehow interfering with `rails-dev-boost`, but no reproducible test case (#36, #43, #50).