-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
[core] Performance improvement for runtime env serialization #48749
base: master
Are you sure you want to change the base?
[core] Performance improvement for runtime env serialization #48749
Conversation
Signed-off-by: dentiny <dentinyhao@gmail.com>
python/ray/remote_function.py
Outdated
# runtime env will be merged and re-serialized. | ||
# | ||
# Caveat: for `func.option().remote()`, we have to recalculate serialized | ||
# runtime env info upon every call. But it's acceptable since pre-calculation |
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.
to be more clear,
To support dynamic runtime envs in `func.option(runtime_env={...}).remote()`, we recalculate the serialized runtime env info in the `option` call. If there are multiple calls to a same option, one can save the calculation by `opt_f = func.option(runtime_env={...}); [opt_f.remote() for i in range(many)]`.
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.
I'm not sure I follow the "If there are multiple calls to a same option" part, since we don't do any caching for option
calls.
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.
Adopted other comments.
Signed-off-by: dentiny <dentinyhao@gmail.com>
Signed-off-by: dentiny <dentinyhao@gmail.com>
Signed-off-by: dentiny <dentinyhao@gmail.com>
stress_test_many_tasks for this PR:
As compared to 2.39: ray/release/perf_metrics/stress_tests/stress_test_many_tasks.json Lines 34 to 45 in 3435c25
It seems stage_2 is better, while other stages are worse. idk if this is expected? |
Signed-off-by: dentiny <dentinyhao@gmail.com>
Signed-off-by: dentiny <dentinyhao@gmail.com>
the updated release test link: https://buildkite.com/ray-project/release/builds/26062#01932d21-694c-4baa-bbc7-e624bdeeb712 |
Many tests failed. |
Signed-off-by: dentiny <dentinyhao@gmail.com>
I made a typo, should be fixed now. |
Signed-off-by: dentiny <dentinyhao@gmail.com>
Signed-off-by: dentiny <dentinyhao@gmail.com>
Addresses issue #48591
The problem is:
runtime_env
inremote
decorator, the parsing and serialization happens for each function invocationparse_runtime_env
, which involves a dictionary to class transformationget_runtime_env_info
, which serialize a class into json formatDiscussed with @rynewang , the proposed solution here is cache pre-calculated serialized runtime env info, so the parsing and serialization only happens once at initialization.
Benchmarked with the test @jjyao mentioned on the ticket, I confirm we could reach similar performance between no env var vs with env var.
Alternatives considered:
functools.cache
forget_runtime_env_info
, which is a stateless function