Tx pool rewrite with multi_index_map

[chenyukang]

What problem does this PR solve?

Problem Summary:

What is changed and how it works?

This PR unifies the pending and gap pool with multi_index_map, with these two benefits:

1. remove duplicated code logic between different pools.
2. we add the same sorting fields for all entries in tx_pool for future improvement
3. easy to implement future requirements such as replace-by-fee strategy.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code ci-runs-only: [ quick_checks, linters ]

Side effects

• Performance regression
• Breaking backward compatibility

This PR may introduce performance regression for tx_pool, another change is we now do double-spend checking when a transaction is added to the pool.

I will do more testing for this change.

Release note

Title Only: Include only the PR title in the release note.
Note: Add a note under the PR title in the release note.

[chenyukang]

@wyjin

I have finished some benchmark testing for comparing develop and this branch, here are some data, FYI:

develop branch, code: https://github.com/chenyukang/ckb/tree/develop-bench

test component::tests::bench::test_container_bench_add        ... bench:   2,144,760 ns/iter (+/- 3,794,550)
test component::tests::bench::test_container_bench_add_remove ... bench:   9,826,341 ns/iter (+/- 336,570)
test component::tests::bench::test_container_bench_sort       ... bench:   4,752,366 ns/iter (+/- 418,446)

current branch bench, code: https://github.com/chenyukang/ckb/tree/tx_pool_refactor_bench

test component::tests::bench::test_container_bench_add        ... bench:   1,956,728 ns/iter (+/- 4,352,650)
test component::tests::bench::test_container_bench_add_remove ... bench:  10,976,779 ns/iter (+/- 174,750)
test component::tests::bench::test_container_bench_sort       ... bench:   3,896,260 ns/iter (+/- 102,732)

It seems sort has been improved.

[wyjin]

@wyjin

I have finished some benchmark testing for comparing develop and this branch, here are some data, FYI:

develop branch, code: https://github.com/chenyukang/ckb/tree/develop-bench

test component::tests::bench::test_container_bench_add        ... bench:   2,144,760 ns/iter (+/- 3,794,550)
test component::tests::bench::test_container_bench_add_remove ... bench:   9,826,341 ns/iter (+/- 336,570)
test component::tests::bench::test_container_bench_sort       ... bench:   4,752,366 ns/iter (+/- 418,446)

current branch bench, code: https://github.com/chenyukang/ckb/tree/tx_pool_refactor_bench

test component::tests::bench::test_container_bench_add        ... bench:   1,956,728 ns/iter (+/- 4,352,650)
test component::tests::bench::test_container_bench_add_remove ... bench:  10,976,779 ns/iter (+/- 174,750)
test component::tests::bench::test_container_bench_sort       ... bench:   3,896,260 ns/iter (+/- 102,732)

It seems sort has been improved.

Is this good enough? remove appears to be slower because size of the pool never exceeds 3. I'd expect to see a major improvement in remove when the pool is bigger and the number of duplications in non-unique fields is also reasonably big.

The develop branch uses the upstream multi_index_map crate. I am curious/worried about how the performance compares to not using multi index map at all. (Is using multi index map causing performance regression?) Seems multi index is used in the ckb2023 branch so probably this test is already done?

[chenyukang]

Is this good enough?

Yes, upstream multi_index_map is used in develop branch, but only for proposed pool. So I want to have a benchmark compare develop with this branch.

From the above benchmark data, we can say the performance is on the same level with trivial difference. I guess this difference won't have too much effect on the whole CKB, since there are rpc operation involved in.

I have concern on the memory, today I write some testing code to verify it. I constantly add parent-child transactions to the pool(this is the worst case, since we need to keep the links).

The memory footprint is:

2w 65.7 MB
3w 86.1 MB
4w 131.5 MB
5w 158.2 MB
6w 201.4 MB

But we have max_ancestors_count to limit the depth.

Anyway, let's wait for the result from acceptance, I talked with them today for the testing.