From 16179b5e55de5f698316f0c63bbe43c008d94ed7 Mon Sep 17 00:00:00 2001 From: Thomas Zarebczan Date: Mon, 25 Mar 2019 15:52:22 -0400 Subject: [PATCH] fix post --- content/news/208-claim-trie-memory-reduction.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/content/news/208-claim-trie-memory-reduction.md b/content/news/208-claim-trie-memory-reduction.md index acf62b35..3810234e 100644 --- a/content/news/208-claim-trie-memory-reduction.md +++ b/content/news/208-claim-trie-memory-reduction.md @@ -1,3 +1,11 @@ +--- +author: samuel-lbryian +title: 'Claim Trie Memory Reduction' +date: '2019-03-25 15:00:00' +cover: 'database2.jpg' +category: technical +--- + # The claim trie memory reduction Here follows a little writeup on some work that we have done to make the data structure in LBRYcrd less naive (and less RAM-hungry). We anticipate that it will ship in a LBRYcrd release in late spring. @@ -172,4 +180,4 @@ Find the index of child starting with nibble n: `popcount(mask & ((1 << n) - 1)` Where popcount represents __builtin_popcountll or some other 64bit intrinsic for accessing the CPU's POPCNT instruction (which counts the number of set bits). -In summary, it's possible to build a very efficient trie structure on top of a simple node definition that includes a sorted or indexed map of the node's children. The deeper the trie goes, the less likely it is to benefit from overlapping keys. There is no reason to use the naive trie in any scenario. \ No newline at end of file +In summary, it's possible to build a very efficient trie structure on top of a simple node definition that includes a sorted or indexed map of the node's children. The deeper the trie goes, the less likely it is to benefit from overlapping keys. There is no reason to use the naive trie in any scenario.