[JS wrapper] Performance issues when used intensively

[genaris]

As part of the integration of Askar with Aries Framework JavaScript, I'm running a test where I set up two Aries JavaScript Agents based on either Indy SDK or Askar and make them connect and exchange a few simple messages.

In that scenario I noticed a very big performance gap: when using two Indy-based agents, the test takes around 300 ms while it takes almost 40 seconds for two Askar agents. When running with a profiler (v8-profiler-next) in both situations I got the following results:

As you can see, in Askar case the CPU spends 80% of its time in Garbage Collector and almost 15% of the time dereferencing pointers and other wrapper-related-stuff.

An interesting issue in ref-napi came after an initial research on this topic. And after applying the patch proposed in a PR and running the tests again, this problem completely disappeared and actually the Askar Agent performed better than the Indy one (as expected).

The problem is that this fix is not working in Node 14.x and 16.x, as it seems that some fixes in v8 engine related to a "Check failed: result.second." (not sure which ones exactly) were not backported and, as a result, this only works in Node 18.

[swcurran]

Are you using a debug build of aries-askar? There is a big performance difference between debug and release versions.

[andrewwhitehead]

The ref-napi issue doesn't seem to be going anywhere at the moment, should we release a final 0.2.8 if it's working on node 18 and try to resolve the performance issue later?

[genaris]

The problem is that, as the things are right now, JS wrapper is not usable at all under Node JS. If we want to make it work in node 18, we need to use a patched version of ref-napi. This can be achieved in multiple ways but I'm not sure what's the best strategy to follow:

• Make @hyperledger/aries-askar-nodejs (and all its dependencies) depend on a patched release: I've created @2060.io/ref-napi for this purpose
• Add a postinstall script that will patch and rebuild ref-napi
• Don't modify anything here: just leave the user application (like AFJ) to do the hard work and patch it or set resolutions field to the patched one

I know the first two options work when dealing with end-user applications, but don't know if they are possible for a "library project" like this one.

The third one can be simpler: we can just explain in the documentation about current limitations under NodeJS environment. However, in AFJ will require some kind of setup logic to fit all cases: remember that this patch makes ref-napi break in node 14/16 (even in those cases where performance is not a problem), so we have to make the patch only if we are using askar (and/or maybe indy-vdr/anoncreds-rs) and we are under node 18.

@blu3beri @TimoGlastra what do you think it could be the best approach in the short term to handle this? This of course assuming that the patch is reliable (we'll probably confirm it shortly as soon as we complete the integration of all shared components in AFJ).

[TimoGlastra]

I would say short term:

• Use your ref-napi package
• Set min node version in the @aries-framework/aries-askar package to 18
• Only run CI for those packages in Node 18

This way we can test the 2e integration, and make sure the api works and we can also leverage it in RN. We keep Askar experimental for now (especially in Node.JS) and then we can later fix the issue properly.

[sandarshanshetty]

WalletError: Error opening wallet mainBob: Cannot read properties of undefined (reading 'storeOpen')
I got this error when opening wallet . should i create any wallet before running this or anything else

[TimoGlastra]

WalletError: Error opening wallet mainBob: Cannot read properties of undefined (reading 'storeOpen')

I got this error when opening wallet . should i create any wallet before running this or anything else

Hi @sandarshanshetty, this question seems unrelated to this topic of this issue, please open a new issue

Edit: i've openend a new issue and posted my answer there