Skip to content
This repository has been archived by the owner on Aug 16, 2022. It is now read-only.

feat: Add S3 Bucket fetch speed improvement #840

Merged
merged 1 commit into from
May 10, 2022

Conversation

spangenberg
Copy link
Contributor

No description provided.

@spangenberg spangenberg added the enhancement New feature or request label May 4, 2022
@spangenberg spangenberg self-assigned this May 4, 2022
@spangenberg spangenberg requested a review from a team as a code owner May 4, 2022 08:18
@spangenberg spangenberg requested review from disq and removed request for a team May 4, 2022 08:18
@github-actions github-actions bot added feat and removed enhancement New feature or request labels May 4, 2022
Copy link
Member

@disq disq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, but why not use a waitgroup and range on the (potentially unbuffered) channel? range would stop iterating when the channel is closed, and no more len(response) business

@spangenberg
Copy link
Contributor Author

lgtm, but why not use a waitgroup and range on the (potentially unbuffered) channel? range would stop iterating when the channel is closed, and no more len(response) business

But the response channel is still needed for the diagnostics, don't see where the WaitGroup would help in that case.

@disq
Copy link
Member

disq commented May 4, 2022

But the response channel is still needed for the diagnostics, don't see where the WaitGroup would help in that case.

Create the waitgroup/goroutines, send stuff to the channel, close the channel, run a range on the errs channel (will need buffered channel or another, single goroutine to read err results into diags...) and to make sure all workers exited, finally do wg.Wait()? Better flow and readability/maintainability imo.

@spangenberg
Copy link
Contributor Author

But the response channel is still needed for the diagnostics, don't see where the WaitGroup would help in that case.

Create the waitgroup/goroutines, send stuff to the channel, close the channel, run a range on the errs channel (will need buffered channel or another, single goroutine to read err results into diags...) and to make sure all workers exited, finally do wg.Wait()? Better flow and readability/maintainability imo.

That makes sense, thanks for clarifying, think this should do it?

Copy link
Contributor

@roneli roneli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

resources/services/s3/buckets.go Show resolved Hide resolved
@spangenberg spangenberg merged commit 0d57a54 into main May 10, 2022
@spangenberg spangenberg deleted the feat/s3-bucket-improvement branch May 10, 2022 14:16
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants