Ipfs-companion: High CPU usage of embedded node

[samuelmaddock]

I installed the Chrome extension earlier today and found it to have high CPU usage. I don't think I was using any IPFS-compatible websites besides checking the ipfs.io blog.

macOS: 10.13.2
Chrome: 65.0.3325.181
IPFS Companion: 2.2.0

[lidel]

Thank you for reporting this. Was it running against external or embedded node?

[samuelmaddock]

Thank you for reporting this. Was it running against external or embedded node?

Embedded node

[lidel]

Embedded node uses js-ipfs, which is not as mature as go-ipfs. I was able to confirm problem under Chromium: after a few minutes with embedded node the CPU usage is indeed very high.

Let's keep this issue open until upstream issues are resolved:

• High CPU when publishing files with js-ipfs https://github.com/ipfs/js-ipfs/issues/1190
• Connection Closing https://github.com/ipfs/js-ipfs/issues/962

---

Workarounds for lowering CPU usage

For the time being I suggest using external node (go-ipfs) which requires smaller amount of resources.
If you run on laptop or other mobile device and want to improve battery life, try additional settings suggested in https://github.com/ipfs/go-ipfs/issues/4137#issuecomment-322557758, namely:

• you probably want to use ipfs daemon --routing=dhtclient
• Its probably also worth turning off the reprovider with: ipfs config Reprovider.Interval "0" so your node doesnt rebroadcast all this things it has every 12 hours.

Also related:

• IPFS light clients https://github.com/ipfs/notes/issues/206
• Low Power Mode https://github.com/ipfs/go-ipfs/issues/4137

[ghost]

Why not just use the new WASM functionality of golang ?
It would keep the J's and golang versions aligned

[lidel]

@gedw99 "just" is bit too optimistic :) We may investigate that route, but my intuition is that it won't be easy. There are low details (such as lack of raw socket API in web browser, storage) that require custom handling etc. Also, there is a huge benefit in having two independent implementations interop in the wild: it verifies if the spec is clear enough.

It may be easier to optimize js-ipfs by introducing WASM (as a technology) in hot paths (eg. crypto), but that is a discussion for https://github.com/ipfs/js-ipfs.