Skip to content

Parallelize merge of per-thread changes into global map. - #5415

Draft
dmkozh wants to merge 2 commits into
stellar:masterfrom
dmkozh:par_commit
Draft

Parallelize merge of per-thread changes into global map.#5415
dmkozh wants to merge 2 commits into
stellar:masterfrom
dmkozh:par_commit

Conversation

@dmkozh

@dmkozh dmkozh commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Description

Parallelize merge of per-thread changes into global map.

When we commit the changes from Soroban apply threads to the global state map, we can shard the output such that every worker only writes into a single shard (thus avoiding any synchronization). Besides the parallelization, this includes a few micro-optimizations that help us avoid extra hash re-computations and copies.

These changes save ~10ms cumulatively on large benchmarks locally.

Checklist

  • Reviewed the contributing document
  • Rebased on top of master (no merge commits)
  • Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
  • Compiles
  • Ran all tests
  • If change impacts performance, include supporting evidence per the performance document

dmkozh added 2 commits August 4, 2026 14:18
While the current logic intertwines reads and writes, in fact it can be cleanly separated into a read-only validation step, and a sequential commit step that simply bumps the sequence numbers and removes pre-authorized tx signers. This is possible because that while the writes change the entries that take part in validation, none of these changes are relevant during the validation. Specifically, sequence number bump is only observable by a single transaction (the one that has the respective account as a source), and the pre-authorized tx signer by definition belongs to a single transaction. There is also a subtle caveat to the latter operation: it increases the available balance of the signer owner (or its sponsor), but since at the pre-apply time the fees have already been charged, we're only checking that the account available balance is non-negative, which is an invariant that must always hold in the current protocol.

The change is not protocol-gated because it's not a protocol change for the *current* protocol. It was technically a protocol change prior to p26 where we had a bug that actually did allow overcharging the fee bump source accounts and thus making their available balance to go negative. However, the bug has been fixed without the behavior ever triggering on-chain, and thus this replay-only behavior change should be non-observable.

This change significantly speeds up the pre-apply step. On the local high TPL benchmarks I'm getting 30-60ms improvement locally compared to the main branch version.
When we commit the changes from Soroban apply threads to the global state map, we can shard the output such that every worker only writes into a single shard (thus avoiding any synchronization). Besides the parallelization, this includes a few micro-optimizations that help us avoid extra hash re-computations and copies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant