-
Notifications
You must be signed in to change notification settings - Fork 21.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid creating controller _helper modules until modification #40204
Conversation
In applications which use :all helpers (the default), most controllers won't be making modifications to their _helpers module. In CRuby this created many ICLASS objects which could cause a large increase in memory usage in applications with many controllers and helpers. To avoid creating unnecessary modules this PR builds modules only when a modification is being made: ethier by calling `helper`, `helper_method`, or through having a default helper (one matching the controller's name) included onto it.
I double checked that even if we build |
Hello @jhawthorn Is it possible to still call previous behavior explicitly? We have an issue on rspec-rails rspec/rspec-rails#2481 that is linked to that change. We define the rails/actionview/lib/action_view/test_case.rb Lines 206 to 218 in 5720165
I tried to play with your patch to fix the issue on the rspec-rails side but I was not able to find the issue. |
Hmm. The pattern linked in that issue looks a bit odd.
If you want the pre-6.1 behaviour I think you could achieve this include directly on I suspect the reason this pattern doesn't pass now is that the helper/view context are being instantiated before the controller includes are performed. I don't think the example in issue is a regression (but I'm not that confident about that 😅). If there was an example which passed in Rails 6.0, didn't modify global state, and now fails on Rails 6.1 I'd love to dig into it ❤️. |
The generated view context classes tend to be fairly complex and use a lot of memory. Similar to how we only generate new helper classes when necessary (see rails#40204) we should be doing the same for view context classes.
The generated view context classes tend to be fairly complex and use a lot of memory. Similar to how we only generate new helper classes when necessary (see rails#40204) we should be doing the same for view context classes.
@jhawthorn I'm using Devise for RailsAdmin with an API-only Rails app, after I upgraded to error:
controller: class Api::V1::AdminsSessionsController < Devise::SessionsController
include ::ActionView::Layouts
layout "admin"
end view:
rspec file: require "rails_helper"
describe "Api::V1::AdminsSessionsController", type: :request do
describe "#new" do
context "when format is html" do
let(:format) { "html" }
it "renders :ok reponse" do
get "/admin/sign_in.#{format}"
expect(response).to have_http_status(:ok)
end
end
end
end |
Hey @M-Sayed, can you create a new issue with a full reproduction repo if you're seeing a regression? Commenting on a 2 year old PR will likely not get much attention |
It seems that the issue is still present. |
In applications which use :all helpers (the default), most controllers won't be making modifications to their _helpers module.
In CRuby this created many ICLASS objects which could cause a large increase in memory usage in applications with many controllers and helpers.
To avoid creating unnecessary modules this PR builds modules only when a modification is being made: ethier by calling
helper
,helper_method
, or through having a default helper (one matching the controller's name) included onto it.