-
Notifications
You must be signed in to change notification settings - Fork 531
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
[Planning Pipeline] Make planning pipeline respect the max. planning time #2581
Comments
This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups. |
Hi @sjahr, I'm interested in working on this issue and have several questions regarding the requirements:
For implementation details, it seems like we can directly modify the |
@TomCC7 Thanks for your interest! Feel free to open a WIP PR with your proposed changes and we can discuss based on the code. Regarding your questions:
Yes! That is one of the biggest shortcomings of the current implementations. Planning time should be the sum of each pipeline component's processing time.
That's a good question. For a first implementation I would propose a naive time distribution: e.g. evenly distributing the time between the planners. The planners usually require significantly more time than the adapters with the current implementations that's why I think we can give each adapter the full remaining budget and it is very unlikely that a large fraction of it is used.
Yes that's a good idea. Make sure that we manage the remaining budget on the pipeline level. So if planner A is quicker than the max. allowed planning time, the "gained" time can be distributed to the other planners. The exact approach to distribute the time can be discussed in the PR itself. I am pretty sure other maintainers have ideas there too |
Thanks for replying! I'll work on this then |
Planning time is currently checked in the planner plugin under the assumption that this is the only process time in the pipeline that consumes a meaningful amount of time. This assumption was wrong and got even more invalidated with the recent refactoring that enables chaining planners.
Planning time should be measured and tracked at the pipeline level when the planning algorithms are called
The text was updated successfully, but these errors were encountered: