Rise concurrency level

[Reinmar]

Right now we use 2-4 processes to work with multiple repos. I raised the number to 4-8 and reduced e.g. mgit update time from about 30-40% (although, more tests would need to be done). It should not make that much difference in case of normal (local) commands, where network is not involved, but those usually take considerably less time anyway.

[Reinmar]

I also tried 30+ threads but that did make any difference. And it actually slowed down mgit st. 4-8 seems to be safest on a typical machine.

[Reinmar]

@pomek Could you do ~5+ tests of the current setting and with 4-8 threads (see utils/createforkpool.js)? GH seems to give quite random numbers so we need more tests to draw conclusions.

[pomek]

Why can't we introduce a property that allows controlling how many threads you would like to use?

GH seems to give quite random numbers so we need more tests to draw conclusions.

That's a reason why my tests won't be good. We need to involve a people that can reproduce an error #92.

[Reinmar]

Why can't we introduce a property that allows controlling how many threads you would like to use?

We can. But we need sensible defaults. If you'll confirm my observations, we can assume this is a common trend. If not, we can check with more people.