if(str1 == str2)与if(str1.length()== str2.length()&& str1 == str2)

我在另一个代码中看到了第二个,我想这个长度比较是为了提高代码生产率.它在解析器中用于具有特定字典的脚本语言:单词长度为4到24个字母,平均为7-8个字母,字母表包括26个拉丁字母加上"@","$"和"_".

长度比较用于转义==运算符使用STL字符串,这显然需要比简单整数比较更多的时间.但同时在给定字典中的第一个字母分布仅比字大小的分布宽,因此比较字符串的两个第一个字母通常通常不同于该字符串的大小.这使长度比较变得不必要.

我已经运行了一些测试,这就是我发现的:测试两个随机字符串比较百万次,第二种方式更快,所以长度比较似乎是有帮助的.但是在一个工作项目中,它在调试模式下运行速度更慢,在发布模式下运行速度更快.

所以,我的问题是:为什么长度比较可以加强比较,为什么它可以减缓它？

UPD:我也不喜欢那种第二种方式,但我认为这是有原因的,我想知道,这是什么原因.

UPD2:说真的,问题不在于如何做到最好.在这种情况下,我甚至不再使用STL字符串了.毫无疑问,长度比较是不必要的和错误的等等.奇迹是 - 它确实在某个特定测试中稍微好一些.这怎么可能？

如果重要,请假设您的库已经完成了.除非真正重要,否则不要以这种方式搞砸你的代码进行微观优化.

什么时候短路可能是有益的

短路优化仅在以下情况下有用:

与完整测试的成本相比,比较成本较低

比较经常导致短路

在数学上,让S为短路状态的成本,F为满状态的成本,P为短路发生的情况的百分比(不需要完全状态).

原案件的平均成本(无短路)为F.

短路优化的平均成本是S + F*(1-P)

因此,如果优化要有任何好处,则必须遵循以下规则:

S + F*(1-P)

即

S

字符串比较成本

你写的更进一步:

这显然比简单的整数比较需要更多的时间.

这根本不明显.字符串比较在找到第一个差异时终止,因此根据您处理的字符串,它可能在绝大多数情况下终止于第一个或第二个字符.此外,只要两个字符串中有足够的数据,通过首先比较DWORDS(一次4个字符),即使对于较长的字符串也可以优化比较.

你的情况

随机测试数据和脚本解析之间的主要区别是真实数据远非随机.解析器很可能是确定性的,一旦匹配,它就不再比较了.即使脚本数据也不是随机的 - 某些关键字可能比其他关键字使用得多.如果解析器以这样的方式构造,它首先检查最常用的关键字,那么令人惊讶的大量比较可能需要完成比较,因为当字符串匹配时总是需要完全比较.

一般来说,你应该把它留给STL而不用担心它.

但是,如果这是一个你需要优化的区域(我非常怀疑),并且如果你理解字符串的字母分布/长度分布,你可以从字符串派生一个新类,并重载==运算符来执行以最有效的方式为您的应用程序进行相等测试.(长度优先,第一个角色优先,前进,后退,等等).

这比在整个代码中分散"优化"要好.