implement xargs -P using rayon and a spin lock#653
Conversation
| batches | ||
| .par_bridge() | ||
| .map(|batch| batch?.execute_parallel(capacity).map_err(XargsError::from)) | ||
| .collect() |
There was a problem hiding this comment.
this is meat of the change, the other option here to avoid would be to build the thread pool directly which would avoid needing a lock but I feel the impl Iterator is a cleaner abstraction and is in line with rayon advice
61aae5c to
e175c3c
Compare
|
if more tests are desired then I have a branch ready to push |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #653 +/- ##
=======================================
Coverage 91.76% 91.77%
=======================================
Files 31 31
Lines 6203 6283 +80
Branches 328 329 +1
=======================================
+ Hits 5692 5766 +74
- Misses 390 394 +4
- Partials 121 123 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
e175c3c to
aa1ec44
Compare
|
Did you run some benchmark on it? |
|
here's a few ad-hoc rough numbers |
|
a few more that probably have more cpu contention |
|
@asakatida |
|
|
btw: |
|
Scenario 3 looks a little disappointing - Would be interesting to see how the performance compares against the implementation without the lock and without using multiple threads at all? (Just use one thread to spawn childs up to MAX_PROC and wait for any to finish) |
if this is accepted then I could do #112 in a similar way