Cache derating_factor for performance
#834
Merged
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.
Description
Calls to
derating_factor(g, tag = r)are a bit expensive as they need to build strings in runtime.It appears in many loops that involve time, so it shows up in profiling as something meaningful.
Here is a benchmark in a case with 26 areas and 10 weeks:
before:
307.276451 seconds (399.25 M allocations: 24.051 GiB, 48.76% gc time)after:
269.367580 seconds (332.77 M allocations: 20.677 GiB, 53.52% gc time)Which is 10% in time and almost 20%(!) in allocations.
What type of PR is this? (check all applicable)
Related Tickets & Documents
none
Checklist
How this can be tested
.
Post-approval checklist for GenX core developers
After the PR is approved