Remove try-except overload to check if some attribute exists #159
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @c0fec0de! I expect that the coverage failure should not be relevant because it failed because I ended with a negative number of lines added. 😅 |
|
Hi @c0fec0de! Any updates about this PR? 🙂 |
|
Nice catch with the attribute name mangling |
|
Merged. Thanks for contributing. |
|
I merged it locally. Will mention you in the release notes. |
|
Hi @c0fec0de! Thanks for accepting muy change. 😉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the current implementation, there are some try-except blocks to check if an object has some attribute. To reduce the generated overhead by the exception handling logic, I propose to start using the
getattrbuiltin function with a default value instead.This change doesn't provide a big performance improvement, but it's a constant-factor cost removal with no public API implications.
To check the difference, I build a
1million node random tree with a height of25. The logic to build theanynode.AnyNodeinstances from the tree encoded as raw dictionaries decreased from~11seconds to~8seconds on my computer (not a big change, but better than nothing 🙂).