-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
data_store: reduce the cost of creating prerequisite objects #5523
Conversation
prereq_buf.conditions.extend(conds) | ||
prereq_buf.cycle_points.extend( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dwsutherland Is there a special why these PbPrerequisite
fields were initialised, then extended rather than being declared directly? It seems to work this way but I know PB ain't Python so can appear to have strange interactions so want to make sure I'm not breaking anything deliberate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may have been a work around to an issue that has been solved:
protocolbuffers/protobuf#10063
Or just a quirk of how I did things (perhaps thinking sub message fields couldn't be in the init args)..
If it works, and results are as expected .. Then should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I've pinged David on Element, for the protobuf question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.. As the prerequisites are stored and used in the pool task, it made sense to reuse this info for the data-store...
Attempt to reduce the overheads of creating prerequisite objects in the data store.
At Cylc7 we only created prerequisite objects for tasks in the pool. At Cylc 8 we create pbPrerequsite objects for each task in the n=1 window by default, expandable out to large n numbers by request.
These prereq objects are costly to generate. The bulk of that is due to a high number of
detokenise
calls. Since there is no real function to having the tokens objects around for data store prerequsites which don't technically exist yet, we may as well go back to string formatting here.Also make some minor optimisations on route and fix what looks like a bug in the expression for non-conditional prerequisites.
Check List
CONTRIBUTING.md
and added my name as a Code Contributor.setup.cfg
(andconda-environment.yml
if present).?.?.x
branch.