I hadn't run any benchmarks myself, but you can estimate the performance based on the few parameters.
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:
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.
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 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.
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.
4I 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. Jan 19, 2018 at 11:01