Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Triecache: Optimize size occupied by SharedNodeCacheMap #7386

Open
alexggh opened this issue Jan 29, 2025 · 0 comments · May be fixed by paritytech/trie#216
Open

Triecache: Optimize size occupied by SharedNodeCacheMap #7386

alexggh opened this issue Jan 29, 2025 · 0 comments · May be fixed by paritytech/trie#216
Assignees

Comments

@alexggh
Copy link
Contributor

alexggh commented Jan 29, 2025

During this #6131 (comment) @bkchr discovered that the inline_size of the SharedCache balloons to 3GiB when running state_access benchmark and to 1.5GiB if you run the read/write storage benchmarks with asset-hub-westend.

This happens because the size_of of NodeOwned structure is 750 bytes, and when it is used here

, makes the LruMap waste of lot of space.

The NodeOwned is that big because of this enum variant, which uses a static array of size 16.

	NibbledBranch(
		NibbleVec,
		[Option<NodeHandleOwned<H>>; nibble_ops::NIBBLE_LENGTH],
		Option<ValueOwned<H>>,
	),

The tests ran on state_access benchmarks and on asset-hub-westend showed that we could reduce the used space by a factor of 4 if the array would be dynamically allocated only for the populated children.

We need to be careful here not to fragment the memory with so many small allocation, see #6131 (comment), one idea @bkchr had is to use an arena allocator.

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 a pull request may close this issue.

1 participant