Repository navigation
[Experimental] Async downloads prototype - #1609
googlyrahman wants to merge 1 commit into
Conversation
Summary of ChangesHello @googlyrahman, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a prototype for an asynchronous client within the Google Cloud Storage SDK, primarily to explore and compare the performance of async downloads against the existing Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces an experimental prototype for asynchronous downloads, including a sliced download strategy for large files. The implementation is a solid starting point. My review focuses on improving code clarity and maintainability by addressing magic numbers, suggesting a more readable approach for chunk calculations, and noting debug print statements that should be replaced with proper logging in a production environment.
| await download_obj.consume(transport, timeout=timeout) | ||
|
|
||
| def _check_if_sliced_download_is_eligible(self, obj_size, checksum): | ||
| if obj_size < 1024*1024*1024: |
| obj_size = blob_obj.size | ||
| try: | ||
| if not sequential_read and self._check_if_sliced_download_is_eligible(obj_size, checksum): # 1GB | ||
| print("Sliced Download Preferred, and Starting...") |
| chunks_offset = [0] + [obj_size//_parts]*(_parts-1) + [obj_size - obj_size//_parts*(_parts-1)] | ||
| for i in range(1, _parts+1): | ||
| chunks_offset[i]+=chunks_offset[i-1] |
There was a problem hiding this comment.
This logic for calculating chunk offsets can be simplified for better readability. A more direct approach would make the intent clearer.
| chunks_offset = [0] + [obj_size//_parts]*(_parts-1) + [obj_size - obj_size//_parts*(_parts-1)] | |
| for i in range(1, _parts+1): | |
| chunks_offset[i]+=chunks_offset[i-1] | |
| chunk_size = obj_size // _parts | |
| chunks_offset = [i * chunk_size for i in range(_parts + 1)] | |
| chunks_offset[-1] = obj_size |
| for file_handle in file_handles: | ||
| file_handle.close() | ||
| else: | ||
| print("Sequential Download Preferred, and Starting...") |
| self._checksum_object = checksum_object | ||
|
|
||
| async with response: | ||
| chunk_size = 4096 * 32 |
The following changes are not meant for merge, as they are prototype-based to compare the performance of gcsfs with async python SDK.