http://blog.huang-wei.com/2010/07/20/%e5%8f%8c%e6%95%b0%e7%bb%84%e5%ad%97%e5%85%b8%e6%a0%91%e7%9a%84%e5%86%85%e5%ad%98%e5%8d%a0%e7%94%a8%e6%b5%8b%e8%af%95/

上一篇文章介绍了双数组字典树 DATrie，现在让我们来简单的测试下内存占用情况。

测试用例，我选了The Holy Bible，数据文件大小为4.2MB。只记录英文单词，全部转为小写。

Trie的实现我已经做了一些优化，初始每个节点的指针数组 size 为0，当有节点插入时，再开 max(size, char) 大小的数组。trie-mem 显示的是已经除去节点自身的大小，即该数值体现的是申请的指针数组总大小。

trie-mem / ptr-size / nodes = 9.1，说明平均每个节点（内节点+叶节点）分配了9.1个指针。相对完全Trie树而言，已经节省了很多空间了。但这样算浪费的量明显是不够精确的，nodes 应该换成内节点数（这里就用 u-words 代替叶节点，虽然两者是不等同的），因为叶节点未分配指针数组，并应该减去真正有用的转移边。这个浪费的值应该是 (trie-mem / ptr-size – nodes) / (nodes – u-words) = 12.8。

DATrie的浪费值应该是 (datrie-mem / (2 * int-size) – nodes) / (nodes – u-words) – 1 = 1.2，可见 DATrie 的空间复杂度还是相当不错的。当然DATrie的实现我还没有进行深入的优化，基本就是上一篇文章里的代码做的测试。如果按那文章里提到的优化方法继续优化，空间的浪费值会更低。

但DATrie存在一个比较大的问题，就是它的空间是预先申请好的，因为根本无从得出它实际的大小，如果空间不够大了再重新分配的话，那势必又得消耗时间，而且还是无法解决空间是否足够的问题。另外，附加的信息域最好保存为指针的形式，否则重排时复制的复杂度就可能会很高。

总结，DATrie还是比较适合在工程中应用，尤其对于数据集比较固定的。