-
-
Save d11wtq/2814849 to your computer and use it in GitHub Desktop.
| # Instructions for use | |
| # | |
| # 1. Execute "time rails runner nil" a few times in your shell, see how long rails takes to boot | |
| # 2. Add this monkey patch to the top of config/boot.rb | |
| # 3. Repeat step 1. What's the difference? | |
| # | |
| # This is just an experiment, but it gains me 30% on Rails' start time, which suggests there is something | |
| # in Rails that is breaking the "run only once" behaviour of #require. | |
| # | |
| # Note: You can't override Kernel#require, since Rails by-passes it most of the time. | |
| class Object | |
| def require_with_dirty_filthy_hack(path) | |
| return false if (@@__seen ||= {})[path] | |
| @@__seen[path] = true | |
| require_without_dirty_filthy_hack(path) | |
| end | |
| alias_method :require_without_dirty_filthy_hack, :require | |
| alias_method :require, :require_with_dirty_filthy_hack | |
| end |
I smell a Rails pull request coming up.
Ok, nobody use this. It's fine in production where cache_classes is om, but in dev class reloading causes issues. Bummer.
That was my initial thought, but I've been using it since you put it up and haven't run into any issues. What specific case would cause a problem?
I did it, then tested that changing classes works fine fyi
It seems to cause issues for us when modules are mixed into our models at runtime... on subsequent requests after the first one, we start getting "uninitialized constant ModuleName" for whatever is supposed to be mixed in, presumably since the 'require' for the module isn't happening correctly the second time around. Maybe there's another workaround.
Are you using require or include?
require to get the module into scope, include to mix it into the model. Do you mean require or load?
I meant require, wondered why you mentioned it since we're using Rails' autoload and don't require it at all - possibly why it still works.
15.75s avg before
13.61s avg after
13.6% decrease