6

The JavaScript Stellar SDK facilitates integration with the Stellar Horizon API server and submission of Stellar transactions, either on Node.js or in the browser. It has two main uses: querying Horizon and building, signing, and submitting transactions to the Stellar network. Is there any difference in speed between the different SDKs?

5

I hadn't run any benchmarks myself, but you can estimate the performance based on the few parameters.

Cryptography

Cryptography is the most CPU-consumptional part of SDK. Stellar JS SDK depends on Ed25519, SHA and CRC. And Ed25519 is the main concern, because the key derivation and signing are implemented on Ed25519 elliptic curves.

If you open stellar-base npm package dependencies, you'll spot two libraries: tweetnacl and ed25519. The first is a JS port of C-based tweetnacl crypto library. Of course, it is 20x-100x times slower than native implementation. So if you are running code in the browser, it will work significantly slower than C implementation on the server. However, the second package (ed25519) is effectively a wrapper for the native Ed25519 standard implementation, so it has close to native performance. Therefore if JS SDK is deployed on the node.js server, it will utilize the CPU-optimized Ed25519 code.

Encoding and serialization

Stellar relies on the XDR serialization and Base32 encoding. Due to the nature of JS virtual machine, the serialization and other algorithms that rely on buffers and encoding are 5x-20x slower than C (Go, C#, Swift etc) implementations.

int64

One of the most problematic things, as JS does not support int64 numbers. Libraries (like bignumber) used to overcome this problem work internally with structures that contain two number properties (hdword, and ldword). All operations with Int64 in JS have performance implications and are 50x-500x slower than native code.

Other code

Other things (like regular code structures, XHR calls, methods invocations) are optimized by JS engines and usually are no more than 2x-5x slower than compiled language analogs.

Conclusion

The elliptic curves cryptography and serialization are the most CPU-consuming parts of the SDK. JS SDK that runs in browser will be around 50x-100x slower that compiled languages (C, Go, Swift, C#) in most real-world scenarios.

However, does the performance really matters in all application types? You will face performance issues only in case of very large throughout, like generating millions of accounts/transactions or parsing the whole ledger.

  • 4
    I would add that after you are finished generating the transaction, you want to send it on the network and wait for a response. That is going to be much much slower than signing and serialization, especially if you use SDF horizon instance. – Francesco Jan 19 '18 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.