Add cache to OptionKey #14250
Add cache to OptionKey #14250
Conversation
bruchar1
force-pushed
the
cached-optionkey
branch
3 times, most recently
from
f52d09e to
9fdbd2b
Compare
bruchar1
force-pushed
the
cached-optionkey
branch
from
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")? |
bruchar1
force-pushed
the
cached-optionkey
branch
from
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. |
bruchar1
force-pushed
the
cached-optionkey
branch
2 times, most recently
from
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) |
bruchar1
force-pushed
the
cached-optionkey
branch
from
a4fab0f to
c06f203
Compare
bruchar1
force-pushed
the
cached-optionkey
branch
from
c06f203 to
ba4be93
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 mesonbuild#14245
bruchar1
force-pushed
the
cached-optionkey
branch
from
ba4be93 to
0093d65
Compare
This removes a few comparisons, and one function call.
It makes object initialisation slower...
bruchar1
force-pushed
the
cached-optionkey
branch
from
0093d65 to
98c5d82
Compare
| @@ -103,8 +102,9 @@ class ArgparseKWs(TypedDict, total=False): | |||
| } | |||
|
|
|||
| _BAD_VALUE = 'Qwert Zuiopü' | |||
| _optionkey_cache: T.Dict[T.Tuple[str, str, MachineChoice], OptionKey] = {} | |||
There was a problem hiding this comment.
Should this be a class object rather than a module level variable?
There was a problem hiding this comment.
It cant be because the class is mucking with __new__
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