Add lru_cache to parsing for improved performance #25
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
4 tasks
mraspaud
approved these changes
May 5, 2020
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.
This adds caching using the standard library's
functools.lru_cacheto theget_convert_dictfunction and theRegexFormatter.formatmethod. These are both used duringparseand only require thefmtand are therefore super easy/efficient to cache. So in the common case (especially Satpy) where we have a single pattern and are checking many other strings against it, this will have a huge impact. In pytroll/satpy#1178, I noticed this change (with ~5600 test strings and 20 format strings) improved my performance from ~4s to ~2.8s.This PR also adds a
purgefunction which allows the user to clear these caches with one single function. However, the default forlru_cachethat we are using is 128 items which really isn't that many so I don't think this should ever be needed.