When the number of entries is large(>= 100000), we observed a performance regression for _update_tx_pool_for_reorg, the delay may longer than a duration of 10s, the RPC send_transaction also has a noticeable delay when the number of entries increasing a lot.
What is changed and how it works?
The performance regression is caused by a slow implementation of track_entry_statics, which will be called when adding a new entry or changing entry status.
entries.get_by_status(&Status::Pending).len() is slow when entries number is large, _update_tx_pool_for_reorg will iterate the proposals to invoke track_entry_statics multiple times(1000+ in corner case).
This PR will add 3 counts to track the number of pending, gap, proposed to resolve the performance issue.
Related changes
PR to update owner/repo:
Need to cherry-pick to the release branch
Check List
Tests
Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code ci-runs-only: [ quick_checks,linters ]
Release note
Title Only: Include only the PR title in the release note.
What problem does this PR solve?
When the number of entries is large(>= 100000), we observed a performance regression for
_update_tx_pool_for_reorg, the delay may longer than a duration of 10s, the RPCsend_transactionalso has a noticeable delay when the number of entries increasing a lot.What is changed and how it works?
The performance regression is caused by a slow implementation of
track_entry_statics, which will be called when adding a new entry or changing entry status.entries.get_by_status(&Status::Pending).len()is slow when entries number is large,_update_tx_pool_for_reorgwill iterate theproposalsto invoketrack_entry_staticsmultiple times(1000+ in corner case).This PR will add 3 counts to track the number of
pending,gap,proposedto resolve the performance issue.Related changes
owner/repo:Check List
Tests
Release note