我在另一个人的代码中看到了第二个长度比较,我认为这种长度比较是为了提高代码生产率。它用于具有特定字典的脚本语言的解析器中:单词长度为4到24个字母,平均为7-8个字母,字母表包括26个拉丁字母加上"@“、"$”和"_“。
使用长度比较来转义处理STL字符串的==操作符,这显然比简单的整数比较需要更多的时间。但在同一时间,给定字典中的第一个字母分布只是比单词大小的分布更宽,因此比较字符串的两个第一个字母通常会比该字符串的大小更不同。这使得长度比较变得不必要。
我已经运行了一些测试,这就是我发现的:当测试两个随机字符串比较百万次时,第二种方法要快得多,所以长度比较似乎是有帮助的。但在一个正在工作的项目中,它在调试模式下工作得更慢,在发布模式下工作得更快。
所以,我的问题是:为什么长度比较可以加速比较,为什么它可以减慢比较?
UPD:我也不喜欢第二种方式,但我想这是有原因的,我想知道,这是什么原因。
UPD2:说真的,问题不在于如何做到最好。在这种情况下,我甚至不再使用STL字符串。难怪长度比较是不必要的,也是错误的,等等。奇怪的是-它在一次特定的测试中确实倾向于稍微好一点。这怎麽可能?
发布于 2008-10-09 09:19:07
在随机测试中,字符串可能足够长以显示增益,而在实际情况中,您可以处理较短的字符串,并且不执行测试的字符串比较部分的增益不会抵消两个比较的恒定因子。
发布于 2008-10-09 09:18:01
如果这很重要,假设你的库已经做到了。不要因为微优化而把代码搞得一团糟,除非它真的很重要。
发布于 2008-10-09 11:17:25
什么时候短路是有益的?
只有在以下情况下,短路优化才会有帮助:
短路
在数学上,假设S是短路条件的成本,F是满条件的成本,P是发生短路的情况的百分比(满条件不是必需的)。
原始情况(无短路)的平均成本为F
短路优化的平均成本为S+F* (1-P)
因此,如果优化要有任何好处,则必须应用以下内容:
S+F* (1-P)
即
S< F*P
字符串比较成本
此外,你还写道:
这显然比简单的整数比较需要更多的时间。
这一点都不明显。字符串比较在发现第一个差异时终止,因此,根据您处理的字符串,在绝大多数情况下,字符串比较可能终止于第一个或第二个字符。此外,即使对于较长的字符串,只要在两个字符串中都有足够的数据,也可以通过首先比较DWORDS (一次4个字符)来优化比较。
你的案例
随机测试数据和脚本解析之间的主要区别是真实数据远不是随机的。解析器很可能是确定性的,一旦匹配,就不再进行比较。即使是脚本数据也不是随机的-一些关键字可能比其他关键字使用得更多。如果解析器的构造方式是首先检查最常用的关键字,则可能需要完成大量的比较,因为当字符串匹配时,总是需要进行完全比较。
https://stackoverflow.com/questions/186494
复制相似问题