本文深入探讨了在字符串集合中查找相同前缀字符串的优化策略，包括朴素方案、离线处理方案和在线处理方案。重点分析了离线处理方案通过排序和二分查找的改进，以及在线处理方案采用字典树的高效性。此外，文章还提出了将中文转换为拼音以适应在线处理的复杂应用，并介绍了自平衡树在查询效率方面的应用。最后，提供了针对不同需求的关键词和新标签，旨在帮助开发者构建更高效的搜索系统。
题目内容
如何设计使得空间和时间复杂度尽量低。
题目分析
1.朴素方案
1 for Si in S: 2 if prefix(Si, P): 3 print Si
2.离线处理方案
1 sort(S) 2 i = lower_bound(S, P) 3 for i = i to N: 4 if not prefix(S[i], P): 5 break 6 print S[i]
3.在线处理方案
3.1字典树
1 def find_prefix(node, deep): 2 if empty(node): #子树为空 3 return 4 5 if deep == len(P): #找到完整P 6 return all_son(node) #返回该子树所有叶节点 7 8 #递归遍历子树 9 find_prefix(son(node, P[deep]), deep+1)
Trie处理流程大致是这样的，单次查询的时间复杂度为O(1)。
在线的处理方式当然也能用在离线上，但这两者的效率谁高谁低？
从时间复杂度上，O(logN)对O(1)，似乎没有啥可比性，但在实践中我们要考虑一些其他因素。
首先，数组的下标访问速度优于树的指针访问（关于这点大家可以反汇编，不要迷信教科书上指针访问必定快于下标访问的结论，这点效率虽然有差，但现代编译器会很好的优化相关代码）。
其次，获取结果的效率，数组的顺序访问也优于树的遍历。树有中间节点的时间消耗，且数组能比较好得被Cache到。
再者，即使N=1G=2^30，logN=30而已，O(logN)数量级和O(1)相比其实不算多坏。
使用数组的方案在实际情况下，往往表现优于Trie，而且程序编写难度低，调试方面也相对轻松。
最最关键的是，Trie在工程上应用面很窄，根本不像其在理论上来的那样强大。
朴素的Trie一般应用在英文场景，数据集庞大且重复率很高的情况下比较适用。
原因就是Trie太费内存，不能应用于中文。基本上可以说，不改造不优化，Trie就是废材。
但Trie多路查找的思想确实很重要，很多变种能得到很好的时空效率。
有些程序员会迷恋甚至迷信各种数据结构在理论上带来的结果，其实我们更应该看清本质，这也是我想写有深度的分析稿子的原因。
关于Trie的优化和改造相关内容，我会再整理一份稿子奉上的，这里先作为一个案例引用。
3.2改造方案
现在的问题是，在线处理我们需要像Trie这样的多路查找树特性，而且要能支持中文。
这里我们可以转换下思路，可以把中文转换成拼音，这样又可以直接套用Trie，只不过多了中文转拼音一个步骤。
转拼音其实不难，就是做个表进行映射下就好了，GBK2.0标准中也就27000+个汉字，处理详细方法在这不累述，请自行google。
如上图，朴素的Trie是按英文字母做边的，而拼音是声母和韵母作为单元。
比如“好”hao，“双”shuang，Tire的做法会使树中间节点冗余，影响查找效率，最重要的是导致内存浪费。
优化方法是将Trie对英文字母的映射改成声母和韵母的映射。
哈，这个说起来简单，实现起来还是有要注意的地方。
Trie对字母的映射，可以简单得开个数组，类似ptr[26]，然后映射就很简单，比如ptr[ch-'a']。
而声母和韵母的映射没这么简单，一般方法就是枚举、二分查找、map、hash，虽然集合不大，但或多或少都需要耗费些时间。
但这个是为减少空间浪费做的一点点时间牺牲，在工程实践上是完全值得的。
有童鞋会说，既然声母和韵母还是要映射，为什么不直接映射中文？
其实不映射中文的原因，在于中文处理本身有难度，字符集大，词组间相同前缀较短，容易给树结构的内存问题雪上加霜。
用拼音的方法，容易合并相关前缀，比如同音不同字的情况。
当然这些空间优势也需要付出一定的时间花费，就是在节点上保存相关词组。
比如图例中的shuang，它可能是“双”，也可能是“爽”。这在查询前缀较短的情况下，词组候选集过大，导致额外的性能瓶颈。
说到这里的时候，大家可能有点迷糊了，既然中文的查找树太费内存不可用，而拼音的查找树又会退化，那怎么解决才好？
在这，我想表明我自己的一个观点，就是特定的复杂的应用应该有量身定做的算法和数据结构，教科书上不可能有现成的方案。所以一个优秀程序员的必经之路，必须要能融会贯通，然后构建出自己的解决方案。
概括下我的思路。对于有更新的在线处理，我们如果采用多路查找树的思想（我这不提Trie了，因为Trie已经被改造的面目全非），可以既照顾到数据集的更新也能兼顾查询效率，两者的时间复杂度都和操作的字符串长度有关，这已是极小的时间花费。
从汉字转为拼音，虽然无法直接映射汉字，导致同音词查询新子问题的出现，但换来了空间可用性。
因而打开了一种新的思路，在这里拼音做了类似一级索引的工作，同音字的筛选就能在小数据集中操作。
上图中，红色表示一级索引，绿色表示二级索引，蓝色表示数据集（蓝色是冗余数据优化），不同的图形表示不同的数据结构。这样在工程上的好处是可以结合多个不同数据结构各自的优点。
一级索引查找方式类似Trie，二级索引可以使用set、map、hash等关联结构，数据集可以使用list、vector等顺序结构。
使用STL的童鞋可以在资料[3]中查询各种结构的用法。
3.3改造方案优化
我们来分析下复杂度，首先分析查询时间复杂度（不算蓝色优化部分）。
一级索引查找时间跟前缀拼音长度有关T(Len(P))。子树遍历跟其大小有关，最坏能到达O(N)。
遍历子树是多路查找树的通病，因为它的中间节点不保存子节点信息，当然你可以选择冗余保存（就是蓝色的功能）。
离线处理时我们说过，实践中结果集R会是一个常数值，所以别担心O(N)，这里我们换成T(R)来计算。
当一级索引节点有匹配时，进入二级索引，这里我们使用STL的set结构来分析。
set使用iterator遍历时，它是字典序的，所以使用lower_bound + iterator就能搞定，时间复杂度是O(logN) + T(R)。
最坏情况下，每个有效节点（除去不完整的拼音节点）只有一个词，这样需要遍历R个有效节点。
时间复杂度为Len(P) + R*(O(logN) + R) = Len(P) + R*O(logN) + R*R，因为Len(P)和R都是常数值，所以最后查询的时间复杂度为O(logN)。
插入操作的流程跟查询类似，时间复杂度也相同，在这就略过了。
从这个角度讲，大家不要太过于迷信大O分析，这只是很粗略的上界，它保证时间效率上的可用性，不代表它的实际运行效率。
所以，见到O(logN)跑的比O(N^2)都慢的程序也是很正常的，很多细节的优化，往往都是根据相关数据和特点在大O系数和常数间挣扎。
3.4自平衡树
估计很多童鞋看上字典树的处理方案已经很头大了，有没有又方便又快捷的方案？
当然有，离线处理我们提到过自平衡树，如std::set,std::map。
在线处理中就很好的用到了它的插入特性，时间复杂度为O(logN)。
然后依然使用lower_bound + iterator方法查询。
这样它的插入和查询也都是O(logN)，那上面的方案跟平衡树方案效率是等同的？
此时，我希望大家能从字典树的复杂度分析过程中找到些灵感，这里我不详述红黑树理论，可参见资料[4]。
总结
好久不写技术blog，语言描述有很多含糊的地方，欢迎各位童鞋指正。
也欢迎提供有趣的题目和更有深度的解法和思路，真心希望程序员这个圈子有更浓技术氛围。
再次欢迎来稿，或者探讨技术相关问题。
邮箱：hwiskey@163.com
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
