Enable WebWorkers to make it go faster

[daviddias]

node-forge supports WebWorkers

enable here: https://github.com/libp2p/js-libp2p-crypto/blob/master/src/keys/rsa.js#L131

[dignifiedquire]

Sorry, but this is already enabled, the default is 2 workers: https://github.com/digitalbazaar/forge/blob/master/js/rsa.js#L1574

[victorb]

Guess it would make sense to set it to os.cpus().length by default (for us at least) rather than 2.

[dignifiedquire]

os is not available in the browser, and web workers are only available in the browser

[Kubuxu]

Why not use -1 as suggested?

[victorb]

os is not available in the browser, and web workers are only available in the browser

Sorry, navigator.hardwareConcurrency would be more appropriate in browser land. Otherwise https://github.com/feross/cpus might help abstract it all away.

[dignifiedquire]

Why not use -1 as suggested?

Yes we could use the internal estimator -1.

[dignifiedquire]

Oh, I'm so sorry everyone libp2p-crypto currently uses the blocking sync version. So this is an issue. It means I need to change the interface, but will do that asap and switch to the faster async version...

[dignifiedquire]

It's not as easy as I would like, as we are depending on this being synchronous in the constructors of js-peer-id and js-peer-info. That means changing this requires as us to refactor the use of all those constructors to methods like createPeerId(cb).

[daviddias]

@dignifiedquire can we get a bench test to run in a couple of laptops to see if node-forge is efficient using WebWorkers? I want to know if we save enough time that justifies all of those changes

[dignifiedquire]

@diasdavid we need to make the change in any case to use webcrypto later down the line, i.e. all crypto operations should be done async everywhere. But will need to generate some tests what speed diffs we get

[dignifiedquire]

Fixed in #12