On 01/09/16 08:08, Dave Reisner wrote: > On Wed, Aug 31, 2016 at 11:18:32PM +0200, Gordian Edenhofer wrote: >>>>> The second probably would not be accepted... >>>> >>>> I urge you to reconsider. Parallelization increases the speed of >>>> this >>> >>> I don't think anyone is suggesting that packaging multiple things in >>> parallel isn't useful. I already suggested that nothing needs to be >>> implemented in bacman proper in order for you to parallelize the >>> work. >>> You can write your own "pbacman" as simply as: >>> >>> for arg; do bacman "$arg" & done; wait >> >> There is a huge difference between flooding your system with ~1000 jobs >> and tightly controlling the maximum number. Adjusting the precise >> number of jobs enables you to organize your resources which itself is >> desirable. > > Then use a program like 'parallel' which has this sort of knob. I really > wonder what it is you're doing that requires running bacman with a large > number of packages with any regularity. >
Gathering the files etc takes no time. It is really the compression that is being made parallel. If only there was a way to set compression to use mutlithreading... As I already stated, I'm not looking to accept the parallel patch. A
