-
Notifications
You must be signed in to change notification settings - Fork 40.6k
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
Optimize CacheKey handling in SpringIterableConfigurationPropertySource #16717
Optimize CacheKey handling in SpringIterableConfigurationPropertySource #16717
Conversation
As an addendum. This brings us pretty close to the performance of 1.5 for such big files.
|
Test failure seems unrelated |
Thanks @dreis2211, sorry about the delay getting to these. I hope to review soon. |
Don't worry. There's release preparation, the new annotations API and it's conference season etc.. Whenever you're ready :) |
This is great!!! I've updated things a little in this commit so that sources actually need to declare themselves as immutable. We can then use a shared cache key that always matches. This should save us from even creating the |
Update `SpringIterableConfigurationPropertySource` so that cache keys do not need to be checked if property sources are immutable. See gh-16717
Make immutable properties more explicit and trust that they truly won't change. See gh-16717
Hi,
as described in #16401 there is an optimization opportunity in
SpringIterableConfigurationPropertySource
when checking for CacheKey equality. Currently, for large Sets this takes a considerable amount of time as the two Sets are usually equal, but not the same instance. This is due to the fact that the internal key inside CacheKey is copied in order to fix #13344 and can thus not benefit from a==
comparison.The idea of this PR is to introduce a flag that effectively disables the copying of the internal key under certain circumstances. Imho, this could be done for
OriginTrackedMapPropertySource
instances which is used to load either.yaml
or.properties
files, which usually shouldn't be a subject of change (and even if require a refresh of some sort). I still implemented an additional check for the size of the internal key in a best effort to track key additions at least forOriginTrackedMapPropertySource
s, too.With the applied changes, I see major improvements compared to a M2 baseline.
Let me know what you think.
Cheers,
Christoph