meson
meson copied to clipboard
mesonbuild
Optimize the OptionKey class more
These changes attempt to make the OptionKey faster to initializer and to compare.
with some light testing this makes initializing options keys roughly 5x as fast (when initializing the same key many times) and comparing two pre-initialized keys roughly twice as fast.
This will conflict with absolutely everything in the optionrefactor branch. :(
I have zero idea why all of the test are failing in CI. They all pass 100% locally
Shouldn't the hash only be used as a quick filter, only to then test the tuple if the hash matches?
Shouldn't the hash only be used as a quick filter, only to then test the tuple if the hash matches?
If the hashes match and they're not equal we have a problem, since that would mean that OptionKey('a') in {OptionKey('a'): ...} would have different behavior than OptionKey('a') == OptionKey('a'), which would seem like a bug.
No, the hash collections always check with __eq__, hashing is only used to start the lookup at a good place.
If you create a subclass of str which always returns 1 for hash, set and dict performance will certainly suck but they will give correct results.
Okay, in that case the commit is bogus and we should just go back to the tuple == tuple thing
@bonzini is right about hash collisions. Sorry for guiding you in the wrong direction...
Like @dnicolodi said, it is possible to implement the cache without breaking the API, using the __new__ method. Here is my try in this: #14250.
