-
Notifications
You must be signed in to change notification settings - Fork 6k
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] Correctly refresh elapsed time in ProgressBar
output
#46974
Conversation
Signed-off-by: Scott Lee <sjl@anyscale.com>
Signed-off-by: Scott Lee <sjl@anyscale.com>
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.
nice
Signed-off-by: Scott Lee <sjl@anyscale.com>
… into 0805-progbar-elapsed
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.
Nice
@@ -320,6 +320,9 @@ def _scheduling_loop_step(self, topology: Topology) -> bool: | |||
# Update the progress bar to reflect scheduling decisions. | |||
for op_state in topology.values(): | |||
op_state.refresh_progress_bar(self._resource_manager) | |||
# Refresh the global progress bar to update elapsed time progress. | |||
if self._global_info and self._global_info._bar: | |||
self._global_info._bar.refresh() |
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.
Should we add a refresh
method to ProgressBar
? My impression is that this is breaking an abstraction barrier by accessing the private ProgressBar._bar
attribute?
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.
yeah good point, that will help clean up the logic as well. added it
Signed-off-by: Scott Lee <sjl@anyscale.com>
…oject#46974) When using Ray Data with a slow UDF for map operators, the progress bar's "elapsed time" item is only updated each time a task finishes. If the task is slow, this means that the elapsed time is left "hanging" and appears to be stuck, when this is not necessarily the case. This PR fixes the refreshing of the progress bar, so that the elapsed time ticks up as expected. For the following example code, we can see the change in behavior in the ticking of the progress bar: ``` import time import ray def f(batch): time.sleep(10) return batch ds = ray.data.range(50, override_num_blocks=50).map(f) ds.materialize() ``` - Before (ticks every 10 seconds): https://github.com/user-attachments/assets/d46f0d6f-dacc-4148-a12c-001fcf44f008 - After (ticks every 1 second): https://github.com/user-attachments/assets/88807215-9e81-434f-b186-b5d597bc3c59 --------- Signed-off-by: Scott Lee <sjl@anyscale.com> Signed-off-by: Dev <dev.goyal@hinge.co>
Why are these changes needed?
When using Ray Data with a slow UDF for map operators, the progress bar's "elapsed time" item is only updated each time a task finishes. If the task is slow, this means that the elapsed time is left "hanging" and appears to be stuck, when this is not necessarily the case.
This PR fixes the refreshing of the progress bar, so that the elapsed time ticks up as expected. For the following example code, we can see the change in behavior in the ticking of the progress bar:
Before (ticks every 10 seconds):
https://github.com/user-attachments/assets/d46f0d6f-dacc-4148-a12c-001fcf44f008
After (ticks every 1 second):
https://github.com/user-attachments/assets/88807215-9e81-434f-b186-b5d597bc3c59
Related issue number
Closes #44689
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.