Add treapNode pool. Reduce cloneTreapNode() allocations. #47
No reviewers
Labels
No labels
ci
claimtrie
consider soon
Epic
good first issue
hacktoberfest
help wanted
mempool
mining
peer
priority: blocker
priority: high
priority: low
priority: medium
rpc
runtime
test
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
ux
wallet
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbcd#47
Loading…
Reference in a new issue
No description provided.
Delete branch "treap_node_pool"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Unbundled from PR https://github.com/lbryio/lbcd/pull/43
See that for usage/testing.
Based on work by @BrannonKing in mem_pressure_try_2 and reduce_memory_pressure.
I am not entirely comfortable with the changes. It's my best attempt to combine original Immutable treap semantics with the way that ffldb/transaction actually wants to use it. I was very successful in reducing temporary allocations, but I'm still not sure it's safe. It could also be fragile if treap is used in different ways in the future.
It seems the changes doesn't translate to the performance in terms of sync time, and memory pressure.
I rebased this changes onto v10.22.102 and did a full sync compare to it. Both took around 12 hours for sync up to 1070K blocks with 5.1 GB memory usage. So I'm inclining to leave this out.
Note:
Currently we, include your contributions, have made a lot efforts to improve performance, and make the user/developer experience much better. And I suspect further tuning would have to involve more deeper and intrusive changes with marginal gain.
With limited bandwidth, we're prioritizing functional parity/compatibility with lbrycrd, and help users migrate to lbcd. Check the RPC Availability page, which tracks the full list of bitcoin-core v22.0.0 RPCs. Those with open issues are reported by users that are missing or have different attributes from lbrycrd.
If interested, we can discuss more on discord ping me @roylee17 or join #lbcd channel.
I'm OK with closing this. It seems likely that network latency/throughput is the controlling factor. Blocks are processed serially during network sync, using a fraction of one CPU. As long as there is some CPU headroom (e.g. second CPU core), the garbage collector is able to run in a second thread without much effect on network sync time.
I don't see an #lbcd on the discord server. All I see is a generic #developers. Is there a second server?
Myself is not very familiar with discord yet. But here's the link, see if that works.
https://discord.gg/KRh5Gdjh
Pull request closed