TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Compressing Radix Trees Without Too Many Tears (2017)

58 pointsby nochover 7 years ago

4 comments

fanf2over 7 years ago
See also djb’s crit-bit trees, which are a tighter and simpler version of PATRICIA trees - <a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;critbit.html" rel="nofollow">https:&#x2F;&#x2F;cr.yp.to&#x2F;critbit.html</a> - and agl‘s nice literate code explanation of how they work - <a href="https:&#x2F;&#x2F;github.com&#x2F;agl&#x2F;critbit&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;agl&#x2F;critbit&#x2F;</a><p>And my qp tries, which are smaller and faster than crit-bit trees <a href="https:&#x2F;&#x2F;dotat.at&#x2F;prog&#x2F;qp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dotat.at&#x2F;prog&#x2F;qp&#x2F;</a>
评论 #16409047 未加载
评论 #16408791 未加载
vbernatover 7 years ago
Radix trees are often used in routing tables. On Linux, for IPv4, there is an additional level of compression to avoid the cost of many intermediate nodes. I&#x27;ve described the algorithm used on Linux here: <a href="https:&#x2F;&#x2F;vincent.bernat.im&#x2F;en&#x2F;blog&#x2F;2017-ipv4-route-lookup-linux#route-lookup-in-a-trie" rel="nofollow">https:&#x2F;&#x2F;vincent.bernat.im&#x2F;en&#x2F;blog&#x2F;2017-ipv4-route-lookup-lin...</a>
danbrucover 7 years ago
An obvious way to save space that is not mentioned is of course not to have alphabet sized pointer arrays in each node and if the alphabet is big, for example Unicode characters, it is not really an option to begin with. In that case you would use some kind of dictionary to store the pointers to child nodes. You can also dynamically switch between different node implementations depending on the number of child nodes.
评论 #16410362 未加载
faragonover 7 years ago
Compressing tree data is not trivial. E.g. using per-node heap allocation could take many times the space of the actual data (memory used by the allocator, metainformation, alignment padding, etc.). Using a custom allocator can reduce the memory usage dramatically.