note that my code sidesteps this problem generally On Wed, Jan 30, 2019 at 3:48 PM roger peppe <rogpe...@gmail.com> wrote:
> On Wed, 30 Jan 2019 at 20:07, 'Bryan Mills' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> The code to sequence the results using a channel is not much more verbose. >> >> That not only avoids the library dependency, but also makes the peak >> memory consumption for the results O(runtime.NumCPU()), instead of O(N) >> with the number of tasks, and allows the output to be streamed instead of >> buffered to a slice. >> >> https://play.golang.org/p/zkBjxlcvESe >> > > Nice! In practice though, I've usually found that I do want to keep the > results around or I don't care about the order at all, so the parallel > package works OK. > > I'd point out one down side to the sequencing approach - one very slow > work item can block the others. For example, NProc is 4, the first item > takes 200 milliseconds to process and all the others take 1 millisecond, > then the first 4 workers have started, none more will be started until the > first has, so the overall time will be quite a bit longer (249ms) than if > they were all allowed to proceed irrespective of order (200ms). > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
