-
-
Notifications
You must be signed in to change notification settings - Fork 719
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
Don't use bytearray().join #8312
Conversation
336ddae
to
15d4832
Compare
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 27 files ± 0 27 suites ±0 15h 5m 29s ⏱️ - 4m 6s For more details on these failures, see this check. Results for commit 9c1e3a8. ± Comparison against base commit 6f9e491. ♻️ This comment has been updated with latest results. |
15d4832
to
9c1e3a8
Compare
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! 👍
If TCP is unaffected, why do we care? The |
Because the tests in |
Note for the future, we should probably get more into the practice of considering nuking things as a viable option. |
I agree that it's silly to maintain two tcp backends and we should either nuke asyncio_tcp and commit to tornado or invest time in fixing asyncio_tcp and nuke tornado. Something to discuss during our next meeting. |
dask/distributed#8312 has changed the `host_array` submodule where it belongs.
If work is being done on |
When merging two uncontiguous frames, don't use
bytearray().join(...)
. Instead use a much faster numpy-based buffer.This can reduce the runtimes of
from_frames
from 60ms to 20ms when receiving a single 128 MiB numpy array sharded in two: