Slow performance with derivePublicKey

[Joohansson]

I tried to get this library working with the latest NPM and react but I couldn't get it to work and ended up completely rebuilding it using react-app-rewired together with worker-loader instead of ejecting the whole project like you did.

It all works great with web workers, multithreading and all and the following code does the address creation and matching (it's taken from this codebase). However I have problem with performance. Without the derivePublicKey below I can do 150,000 loops per second. With the derivePublicKey the performance drops to 600/s. Another strange thing is that there is no difference using 2 threads or 12 when doing that. Just using "currentAddressesCount += 1" boost the loop count to 120 million per second so nothing wrong with the multithreading implementation. Using nanoaddr.io on the same machine gives 70,000 addresses per second so I know it should be possible to boost. I just don't understand what's wrong. Do you remember running into that issue? And how did you solve it? Any help you could give is greatly appreciated. You can reach me on discord in the Nano server as Json.

The new tool will be part of a complete set of web tools I'm building for Nano and I will reference this repo as a source.

function search() {
  currentAddressesCount += 1
  const array = new Uint8Array(32)
  // eslint-disable-next-line no-restricted-globals
  self.crypto.getRandomValues(array)
  const seed = array.reduce((hex, idx) => hex + (`0${idx.toString(16)}`).slice(-2), '')
  const secretKey = nano.deriveSecretKey(seed, 0)
  const publicKey = nano.derivePublicKey(secretKey)
  const address = nano.deriveAddress(publicKey, {useNanoPrefix: true})

  if (isMatch(address)) {
    postMessage(address)
  }
}

[Joohansson]

I have now verified that running [email protected] with await nanocurrency.init() indeed result in 10,000 keys/s per thread compared to 300/s per thread with [email protected] which has no init() function. Easy to test with https://github.com/vitorcremonez/nano-vanity by doing npm install and jumping between the two versions. So something has changed with that library.

Also tested with my own multithreading script and getting 70-120k per sec using 12 threads, with 1.7.4.

[njakob]

First of all, thank you for your interest into this project!

As I wanted to point to the underlying library responsible for the Nano related operations (marvinroger/nanocurrency-js) in ran into another issue you opend marvinroger/nanocurrency-js#75.

A while back, the creator of the library switched most of the WebAssembly implementation to JavaScript due to maintainability marvinroger/nanocurrency-js#24. This is the reason why you're seeing such a big different between [email protected] and [email protected].

[Joohansson]

Ah, that makes sense, thanks for pointing to that issue!
I ended up using both versions since npm now allows the use of tags. I'm using the new library for everything that does not require web workers with multithreading. I guess he never implemented that special function he talked about?

package.json

"nanocurrency174": "npm:nanocurrency@^1.7.4",
"nanocurrency230": "npm:nanocurrency@^2.3.0",

worker

import * as nano from 'nanocurrency230'
import * as nano_old from 'nanocurrency174'