Performance Improvements, pt. II

[arboleya]

Building upon part one (#3576) of this series, and while we strive for faster transaction processing time, we should now dissect everything from start to end regarding all network requests necessary for the entire transaction flow and cycle—but now from a browser perspective.

Unlike in part one, this chapter must go beyond the submission and analyze everything that happens until the end, including transaction settlement and (optional) retrieval. It should not be limited to the SDK but include everything from a connectors/wallet perspective, which will inevitably shift the focus to front-end applications.

We should be creative and consider optimistic techniques and whatever else we can.

The end goal is to make tx's super snappy.

cc @LuizAsFight

[danielbate]

We have now completely dissected the end to end transaction process, the full report can be found here.

For the end to end transaction flow, improvements can be summarised as follows:

• Transactions are pre-loaded (if possible) and estimated and funded through an improved dry-run endpoint, as outlined in Performance Improvements, pt. I #3576.
• Data transmission between the SDK and Wallet is improved through changes to the JSON RPC interface to give the wallet more context of actions that have already been performed by the SDK, to reduce redundancy and network calls being performed by the wallet
• Wallet level transaction simulation after signing is optional, to negate unnecessary simulation
• Tx submission is owned by the SDK, to reduce the number of calls required to build a transaction summary

Follow up issues will soon follow and be posted in this issue, but will then supersede this issue.

[danielbate]

This issue is being superseded by the issues that were the outcome of this investigation:

• Inverted Submission Flow #3665
• Improve SDK and Wallet Communication #3669