Add task pool

[Azer0s]

This is more of a prototype right now but it is already a bit faster than the normal lop.Map implementation.

Running on M1 Macbook Pro 2021

[Azer0s]

Currently I have a return slice and just map the values with a function, I will change this however to let the users manage return data themselves

[Azer0s]

Alright, done. Made it a bit faster even

[Azer0s]

I have done some benchmarks and will commit them later. As of right now, the task pool implementation is about 4x faster.

[samber]

Thanks for your contrib @Azer0s !

I made a few comments

[Azer0s]

Refactored everything according to comments. Shall I add some doc in README? @samber

[samber]

Yes please!

Can you update the benchmark at the bottom of README?

[Azer0s]

@samber Done. Could you look through the documentation I added?

[Azer0s]

@samber I added another helper function called With. This is useful for the situations described in the readme and for some situations with the taskpool.

[Azer0s]

please merge @samber

[Bin-Huang]

Good job. But maybe the API that implemented with method With() is a little complex to use?

I think expandable optional parameters might be more suitable:

func Map[T any, R any](collection []T, iteratee func(T, int) R, options ...*ParallelOption) []R {
}

// Usage Cases:

// set max concurrency count with option
parallel.Map(collection, callback, parallel.Option().Concurrency(20))

// normal calling
parallel.Map(collection, callback)

// expandable to more options in future
options := parallel.Option()
options.Concurrency(10)
options.Timeout(2 * time.Second)
options.Retries(3)
parallel.Map(collection, callback, options)

By the way, this design with optional parameters was well-practiced in other language communities:

Node.js p-map

await pMap(array, callback, { concurrency: 20 })

Node.js bluebird

await Bluebird.map(array, callback, { concurrency: 20 })

Node.js prray

await Prray.from(array).mapAsync(callback, { concurrency: 20 })

[Azer0s]

@Bin-Huang Ok I found a solution that imo is a bit more elegant.
Kind of a compromise between your and my solution.

Could you take a look? @Bin-Huang @samber

[Bin-Huang]

@Azer0s @samber
I also wrote some code this weekend, maybe we can share more ideas on the code.

#81

[Bin-Huang]

Is it runtime.NumCPU() can be 1, then DefaultPoolSize will be zero?

[Bin-Huang]

I know some use cases will cause confusing default behavior about default pool size.

Let says someone wants to request 10 URLs in parallel on a device had 2 CPUs, he will write some code just like that:

responses := parallel.Map(URLs, request)

In this case, requesting a URL is only an IO-intensive task, so for the best performance and efficiency, it should requesting 10 URLs at the same time, just like the code above looks like for the package user.

But DefaultPoolSize is working internally and it is 1 (half of the CPU number), so actually, only one requesting task is started at the same time. And in this case, someone will confused about why the code will be slower 10x times.

The task pool can improve performance only if the developer knows what they doing, and adjusts the pool size thoughtfully for the special scene. A global default pool size can't improve performance in any scene, and often it's worse (if it can, the Golang GMP will make it internally).

I recommend removing the default pool size, and only using the task pool when the concurrency limit option is set.

[yujiachen-y]

I think this PR is very useful, are we planing to merge it? 😂

[brettmorien]

Would love to see this feature. Bit of a blocker to have unlimited goroutines getting spun up when using parallel functions.

[kcmvp]

These methods are very useful, when those are be merged ?

[kcmvp]

@Azer0s thank your great contribution very much! I like these feature as well. Could please resolve the conflicts and merge it ? @samber

[Azer0s]

@kcmvp @Bin-Huang is this still relevant? If so I can fix the conflicts and merge