-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add cache to OptionKey #14250
base: master
Are you sure you want to change the base?
Add cache to OptionKey #14250
Conversation
f52d09e
to
9fdbd2b
Compare
9fdbd2b
to
ea79fd5
Compare
Do you even need to override equality if there's a cache? Wouldn't all equal objects be the same object (i.e. "a == b" becomes the same as "a is b")? |
OptionKey objects are used extensively. We want them with a simple API, but they also need to be optimized to not compromise meson performances. Since this is an immutable object, it is possible to cache the OptionKey object creation. We need to do it using the __new__ to make the caching mechanism transparent. Fixes mesonbuild#14245
ea79fd5
to
7ee66f2
Compare
That's a good point. However, I don't see any hit on comparison operators in my profile. Therefore, I suppose Python already recognize the identity of objects when performing hash map lookup. |
a4ade37
to
a4fab0f
Compare
With those optimisations, target generation is now even faster that before the merge of the options refactor (before options refactor: 73s, after options refactor: 77s, with those optimisations: 64s) |
This removes a few comparisons, and one function call.
It makes object initialisation slower...
a4fab0f
to
c06f203
Compare
OptionKey objects are used extensively. We want them with a simple API, but they also need to be optimized to not compromise meson performances.
Since this is an immutable object, it is possible to cache the OptionKey object creation. We need to do it using the new to make the caching mechanism transparent.
Fixes #14245