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
Ideas to reduce the CPU impact of this middleware #21
Comments
Yeah both seem sensible. I doubt you can spot this middleware in your benchmarking though! If you want to tackle them in a PR, please feel free. |
rik
added a commit
to rik/django-feature-policy
that referenced
this issue
May 7, 2019
- Use a set for faster membership test - Generate the header once at boot time - Disable the middleware if no header need to be added fixes adamchainz#21
I haven't benchmarked it and you are probably right. It's just that I saw those opportunities to not work on every request. |
adamchainz
pushed a commit
to rik/django-feature-policy
that referenced
this issue
May 8, 2019
- Use a set for faster membership test - Generate the header once at boot time - Disable the middleware if no header need to be added fixes adamchainz#21
adamchainz
pushed a commit
that referenced
this issue
May 8, 2019
- Use a set for faster membership test - Generate the header once at boot time fixes #21
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've had two ideas to save some CPU cycles but before implementing them, I wanted to check if you'd be interested in those changes:
FEATURE_NAMES
to a set to speed upif feature not in FEATURE_NAMES
__init__
. Django settings are not supposed to change so__call__
could write the string into the header. That means usingdjango.test.signals.setting_changed
for testing purposes though.The text was updated successfully, but these errors were encountered: