Disable read-backpressure in the crt-c runner #70
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue:
The
crt-c
runner had worse performance than thecrt-python
runner in single-file-download-to-disk workloads, which is odd. You'd thinkcrt-c
would be faster, since it's doing pretty much the same thing, and doesn't involve the Python GIL.Research:
The difference is:
crt-c
was using read-backpressure, andcrt-python
wasn't.Description of changes:
Disable read-backpressure in the
crt-c
runner. It can rely solely on the memory-limiter to keep memory usage down, since it always processes data synchronously within the body callback.I'll keep the code in there, for future testing of backpressure. But it's disabled for now.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.