-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Stop using ReleasableLock in o.e.c.cache.Cache to save O(10M) in heap #107555
Stop using ReleasableLock in o.e.c.cache.Cache to save O(10M) in heap #107555
Conversation
I have a couple heap dumps that show the lock wrapper alone waste O(10M) in heap for these things. Also, I suspect the indirection does cost non-trivial performance here in some cases. => lets spend a couple more lines of code to save that overhead
Pinging @elastic/es-core-infra (Team:Core/Infra) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. May be worth a comment so a future refactor doesn't change it back...
Thanks Simon! I wonder, should we maybe just do away with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM2
There's various other usages of ReleasableLock
on hot-ish paths too (particularly in the engine and translog subsystems) that might want the same treatment.
Yea lets do that asap, I can do it on the side today :) I'm starting to get the feeling the overhead here is more than my initial intuition suggested actually ... |
As discussed in elastic#107555 there's some overhead to the use of `ReleasableLock` and it's probably not a good idea using it on the hot(ish) path in this class.
As discussed in #107555 there's some overhead to the use of `ReleasableLock` and it's probably not a good idea using it on the hot(ish) path in this class.
Hello, |
I have a couple heap dumps that show the lock wrapper alone waste O(10M) in heap for these things. Also, I suspect the indirection does cost non-trivial performance here in some cases.
=> lets spend a couple more lines of code to save that overhead