在C + +：为什么std::string操作不执行？

Why do std::string operations perform poorly?

为了选择服务器端应用程序的语言，我做了一个测试来比较几种语言中的字符串操作。直到我最终尝试C++，结果才是正常的，这让我很吃惊。所以我想知道我是否错过了任何优化，来这里寻求帮助。

测试主要是密集的字符串操作，包括连接和搜索。测试在Ubuntu 11.10 AMD64上进行，GCC版本为4.6.1。机器是Dell Optiplex 960，带有4G RAM和四核CPU。

在python(2.7.2)中：

1
2
3
4
5
6
7
8
9
10

def test():
x =""
limit = 102 * 1024
while len(x) < limit:
x +="X"
if x.find("ABCDEFGHIJKLMNOPQRSTUVWXYZ", 0) > 0:
print("Oh my god, this is impossible!")
print("x's length is : %d" % len(x))

test()

结果是：

1
2
3
4
5

x's length is : 104448

real 0m8.799s
user 0m8.769s
sys 0m0.008s

在Java(OpenJDK-7)中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class test {
public static void main(String[] args) {
int x = 0;
int limit = 102 * 1024;
String s="";
for (; s.length() < limit;) {
s +="X";
if (s.indexOf("ABCDEFGHIJKLMNOPQRSTUVWXYZ") > 0)
System.out.printf("Find!
");
}
System.out.printf("x's length = %d
", s.length());
}
}

结果是：

1
2
3
4
5

x's length = 104448

real 0m50.436s
user 0m50.431s
sys 0m0.488s

在javascript中(nodejs 0.6.3)

1
2
3
4
5
6
7
8
9
10
11

function test()
{
var x ="";
var limit = 102 * 1024;
while (x.length < limit) {
x +="X";
if (x.indexOf("ABCDEFGHIJKLMNOPQRSTUVWXYZ", 0) > 0)
console.log("OK");
}
console.log("x's length =" + x.length);
}();

结果是：

1
2
3
4
5

x's length = 104448

real 0m3.115s
user 0m3.084s
sys 0m0.048s

在C++中(G++—Ofast)

NoDEJS比Python或Java更好，这并不奇怪。但我希望libstdc++比nodejs能提供更好的性能，它的结果真的让我吃惊。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#include <iostream>
#include <string>
using namespace std;
void test()
{
int x = 0;
int limit = 102 * 1024;
string s("");
for (; s.size() < limit;) {
s +="X";
if (s.find("ABCDEFGHIJKLMNOPQRSTUVWXYZ", 0) != string::npos)
cout <<"Find!" << endl;
}
cout <<"x's length =" << s.size() << endl;
}

int main()
{
test();
}

结果是：

1
2
3
4
5

x length = 104448

real 0m5.905s
user 0m5.900s
sys 0m0.000s

小结

好的，现在让我们看看总结：

nodejs上的javascript(V8)：3.1
cpython 2.7.2上的python:8.8s
用LIbSTDC++ ++：5.9s
基于OpenJDK 7的Java：50.4S

真想不到！我尝试了"-O2，-O3"的C++，但没有帮助。在V8中，C++似乎只有50%的JavaScript性能，甚至比CPython还要差。如果我错过了GCC中的一些优化，有人能给我解释一下吗？还是这样？非常感谢。

相关讨论

Java真的是50年代吗？
您正在测试混合操作，您可能应该尝试将测试分为不同的测试，这些测试执行不同的性能检查，例如：增加字符串、查找或…目前你不知道时间花在哪里。顺便说一句，这可能是一个非常无用的测试来决定一种语言…
在循环之前尝试s.reserve(limit);。
@ AshBurlaczenko可能是因为Java中的字符串是不可变的。我想s +="X"是一个性能杀手。这就是StringBuilder存在的原因。
是啊，已经50多岁了，我试过几次了。不过，我认为Java至少比Python更好。
去掉测试中的控制台输出，它将扭曲您的结果。
AshBurlaczenko：在Java中，字符串是不可变的，汇集起来，因此死缓。通常使用StringBuilder来组装字符串。不管怎样，这整件事都是在比较苹果和桔子。
在结果中还包括每种语言的运行时启动和终止。
@AndrewWalker我不认为控制台输出应该发生，除了结尾的一行…
也可以尝试其他编译器。我使用Visual Studio 2010编译了示例。在Xeon 2.8 GHz上运行1.79秒。
@大卫：如果我单独测试每种类型的操作是没有意义的，因为在所有操作中不会有赢家。这个测试是模拟一个服务器守护进程，该守护进程在套接字上监听或在终端上等待字符流，并实时分析它。但是为了简单起见，测试程序省略了很多不那么相关的操作。
@武术：你打算一次装一个角色吗？如果是这样，那么这个测试就代表了您的用法，最好的方法不是确定一种语言，而是寻找一种更好的方法。划分测试将提供更多的信息，因为它将让您知道每种语言中最昂贵的操作，从而使您能够为此优化处理，但测试仍然是荒谬的。在C++中，从EDCOX1到3 EDX1(4)的变化可能比其他语言的差异有更大的影响。
ERM，C++如何比CPython执行得更差？(用C++显示5.5s，用cPython显示8.8秒)
不是与C++部分相关的问题，但Matt Joiner对Java解决方案的评估是正确的。使用StringBuffer连接而不是字符串。Java字符串是不可变的，它将在每次+=时创建一个新字符串。从DOCS.Oracle、COM/JavaSe/1.5.0/DOCS/API/Java/Lang//Helip；"一个字符串缓冲区就像一个字符串，但是可以被修改。"
@RedSoftAdair我确认不同的编译器可以帮助您。在我的机器上用(Visual Studio 2010)进行编译时，cl/ehsc-o2给出1.753 s(接近您的结果)，而python 2.7.1给出6.266 s(也或多或少符合op结果)。
您应该请求了解该语言的人来实现您的测试用例。简单地使用Java中的StrugBu建器将运行时间从我的机器上的75秒缩短到4秒。
@大卫：我试过S.Push-Back(‘X’)但是只改进了大约0.1秒。至于其他人和我的选择，瓶颈主要是搜索过程。我还测试了字符串：：find在禁用"-o"时比strstr或memmem快，但在启用"-o2"时慢得多。所以字符串：：查找可能很难优化。
比利：嗯，用"时间"命令直接比较CPython和C++是不公平的，因为CPython比C++花费更多的时间来启动引擎，也就是加载和编译成字节码。所以我假设cPython更快，如果C++没有超过更多，当然，不是很准确。
@阿什布拉琴科：是的，你是对的。我用StringBuilder和JAVA测试了2.8s的分数，这是所有测试中最好的性能，当然在纯C(大约1.6s)下仍然比STRSTR慢。奇怪的是，StringBuilder的Java仍然比我的ThinkPad R400笔记本电脑的NoDEJs慢了大约30%。
吴：您可以对Java或节点进行同样的论证。(尝试编写一个最小的hello world python应用程序，并从基准测试所花费的时间中减去所花费的时间；这样可以消除启动延迟)
@Plasmah注意到lua字符串也是不可变的，并且是集合的(实习的)，我发现这个测试的lua版本的运行速度是下一个速度最快的执行者(nodejs/v8)的两倍。[Lua约1.5秒，Nodejs约3.1秒]
您可能还想尝试配置文件优化的优化——在C和C++中，对于这样的循环(No.js/v8肯定是用这样的东西编译)是很有意义的。
似乎gnu libstdc++内联为std:：string find编写了一个for循环。哑巴移动。memmem和strstr在汇编中利用SSE2和SSE4扩展使用手写版本进行了更优化。

并不是EDCOX1 1的执行不好(就像我不喜欢C++)一样，字符串处理对于其他语言来说是非常优化的。

您对字符串性能的比较是误导性的，如果它们的目的不仅仅是为了表示这一点，那么它们是自以为是的。

我知道python字符串对象完全是在C中实现的，实际上在python 2.7上，由于unicode字符串和字节之间缺乏分离，因此存在许多优化。如果您在python 3.x上运行这个测试，您会发现它慢得多。

Javascript有许多高度优化的实现。可以预料，这里的字符串处理非常出色。

您的Java结果可能是由于字符串处理不当或其他一些糟糕的情况造成的。我希望Java专家可以介入并通过一些更改来修复这个测试。

至于C++实例，我预计性能会略微超过Python版本。它执行相同的操作，同时减少了解释程序开销。这反映在您的结果中。在使用s.reserve(limit);进行测试之前，将消除重新分配开销。

我重复一遍，您只测试语言实现的一个方面。此测试的结果不反映总体语言速度。

我提供了一个C版本来展示这样的比赛有多么愚蠢：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>

void test()
{
int limit = 102 * 1024;
char s[limit];
size_t size = 0;
while (size < limit) {
s[size++] = 'X';
if (memmem(s, size,"ABCDEFGHIJKLMNOPQRSTUVWXYZ", 26)) {
fprintf(stderr,"zomg
");
return;
}
}
printf("x's length = %zu
", size);
}

int main()
{
test();
return 0;
}

时机：

1
2
3
4
5
6

matt@stanley:~/Desktop$ time ./smash
x's length = 104448

real 0m0.681s
user 0m0.680s
sys 0m0.000s

相关讨论

所以我在ideone.org上玩过。

这里是你原来的C++程序的一个稍微修改过的版本，但是在循环中添加了它，所以它只测量了对EDCOX1的调用(10)。请注意，我必须将迭代次数减少到约40%，否则ideone.org会终止进程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <iostream>
#include <string>

int main()
{
const std::string::size_type limit = 42 * 1024;
unsigned int found = 0;

//std::string s;
std::string s(limit, 'X');
for (std::string::size_type i = 0; i < limit; ++i) {
//s += 'X';
if (s.find("ABCDEFGHIJKLMNOPQRSTUVWXYZ", 0) != std::string::npos)
++found;
}

if(found > 0)
std::cout <<"Found" << found <<" times!
";
std::cout <<"x's length =" << s.size() << '
';

return 0;
}

我在ideone.org上的结果是time: 3.37s。(当然，这是非常可疑的，但请容我一会儿，等待另一个结果。)

现在，我们使用这段代码并交换注释行，以测试附加，而不是查找。注意，这一次，在尝试查看任何时间结果时，我增加了10倍的迭代次数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <iostream>
#include <string>

int main()
{
const std::string::size_type limit = 1020 * 1024;
unsigned int found = 0;

std::string s;
//std::string s(limit, 'X');
for (std::string::size_type i = 0; i < limit; ++i) {
s += 'X';
//if (s.find("ABCDEFGHIJKLMNOPQRSTUVWXYZ", 0) != std::string::npos)
// ++found;
}

if(found > 0)
std::cout <<"Found" << found <<" times!
";
std::cout <<"x's length =" << s.size() << '
';

return 0;
}

尽管迭代次数增加了10倍，但我在ideone.org上的结果是time: 0s。

我的结论是：在C++中，这个基准是由搜索操作高度控制的，在循环中字符的附加对结果没有影响。这真的是你的意图吗？

相关讨论

惯用的C++解决方案是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#include <iostream>
#include <string>
#include

int main()
{
const int limit = 102 * 1024;
std::string s;
s.reserve(limit);

const std::string pattern("ABCDEFGHIJKLMNOPQRSTUVWXYZ");

for (int i = 0; i < limit; ++i) {
s += 'X';
if (std::search(s.begin(), s.end(), pattern.begin(), pattern.end()) != s.end())
std::cout <<"Omg Wtf found!";
}
std::cout <<"X's length =" << s.size();
return 0;
}

我可以通过将字符串放在堆栈上并使用memmem来大大加快速度——但似乎没有必要。在我的机器上运行，这已经是Python解决方案速度的10倍多了。

[在我的笔记本电脑上]

时间/测试X的长度=104448实际0m2.055s用户0m2.049sSsys 0M0.1001S

相关讨论

这是最明显的一个：请在主循环之前尝试执行s.reserve(limit);。

文件在这里。

我要提到的是，在C++中直接使用标准类的方式与Java或Python中使用的标准类相同，如果您不知道书桌后面做了什么，通常会给您提供低于标准的性能。语言本身并没有神奇的表现，它只是给了你正确的工具。

相关讨论

这里缺少的是查找搜索固有的复杂性。

您正在执行搜索102 * 1024次(104448)。一个简单的搜索算法每次都会尝试匹配模式，从第一个字符开始，然后是第二个字符，等等。

因此，您有一个字符串，它从长度1到EDCOX1(18)，并且在每个步骤中搜索该字符串的模式，这是C++中的线性操作。这就是N * (N+1) / 2 = 5 454 744 576比较。我不像你那么惊讶，这需要一些时间…

让我们通过使用搜索单个A的find的过载来验证假设：

1 2	Original: 6.94938e+06 ms Char : 2.10709e+06 ms

大约快3倍，所以我们在同一个数量级内。因此，使用一个完整的字符串并不是很有趣。

结论？也许可以对find进行一点优化。但这个问题不值得。

注：对于那些吹捧博伊尔·摩尔的人来说，恐怕针太小了，所以没什么用。可以减少一个数量级(26个字符)，但不能再减少。

相关讨论

我的第一个想法是没有问题。

C++提供了第二个最佳性能，比Java快十倍。也许除了Java之外，所有的运行都接近实现该功能的最佳性能，您应该看看如何修复Java问题(提示-EDCOX1，0)。

在C++案例中，有一些事情试图提高性能一点。特别地。。。

s += 'X';而不是s +="X";。
在循环外声明string searchpattern ("ABCDEFGHIJKLMNOPQRSTUVWXYZ");，并将其传递给find调用。一个std::string实例知道它自己的长度，而一个c字符串需要一个线性时间检查来确定它的长度，这可能(或不可能)与std::string::find的性能有关。
尝试使用EDCOX1，7，因为类似的原因，为什么你应该使用EDCOX1，0，Java，虽然最有可能的重复转换回EDCOX1，9，将产生更多的问题。

总的来说，结果并不令人惊讶。JavaScript，具有良好的JIT编译器，在这种情况下，可以比C++静态优化稍微好一些。

有足够的工作，你应该总是能够优化C++比JavaScript更好，但是总会有这样的情况，这不仅仅是自然发生的，而且可能需要相当多的知识和努力来实现它。

相关讨论

C/C++语言是不容易的，需要数年才能制作出快速的程序。

使用从C版本修改的strncmp(3)版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>

void test()
{
int limit = 102 * 1024;
char s[limit];
size_t size = 0;
while (size < limit) {
s[size++] = 'X';
if (!strncmp(s,"ABCDEFGHIJKLMNOPQRSTUVWXYZ", 26)) {
fprintf(stderr,"zomg
");
return;
}
}
printf("x's length = %zu
", size);
}

int main()
{
test();
return 0;
}

对于C++，尝试使用EDCOX1对"ABCDFEGHKLMNOPPQRSTUVWXYZ"1来实现——在我的实现EDCOX1中，4计算字符串参数的长度。

相关讨论

我自己刚刚测试了C++示例。如果我取消对std::sting::find的调用，程序将立即终止。因此，字符串连接期间的分配在这里是没有问题的。

如果我添加一个变量sdt::string abc ="ABCDEFGHIJKLMNOPQRSTUVWXYZ"，并替换std::string::find调用中出现的"abc…xyz"，程序需要几乎与原始示例相同的时间来完成。这再次表明，分配和计算字符串的长度不会给运行时增加太多内容。

因此，对于您的示例来说，libstdc++使用的字符串搜索算法似乎不如javascript或python的搜索算法快。也许你想用你自己的字符串搜索算法再次尝试C++，它更适合你的目的。

相关讨论

您的测试代码正在检查过多字符串串联的病理情况。(测试中的字符串搜索部分可能被省略了，我敢打赌，它对最终结果几乎没有任何作用。)过多的字符串连接是一个陷阱，大多数语言都强烈警告不要这样做，并为(即，stringbuilder)提供非常著名的替代方法，所以您在这里测试的本质是在完全预期失败的情况下，ESE语言会失败。那是毫无意义的。

类似的无意义测试的一个例子是，比较各种语言在紧密循环中抛出和捕获异常时的性能。所有语言都警告说异常的抛出和捕获速度非常慢。它们没有指定速度有多慢，只是警告您不要期待任何事情。因此，继续进行精确的测试是毫无意义的。

因此，重复测试会更有意义，用这些语言中的每一种提供的任何构造替换无意识的字符串连接部分(s+="x")，以避免字符串连接。(例如，类StringBuilder。)

相关讨论

我刚刚检查了示例代码，结果发现几乎所有的运行时都是在字符串搜索期间花费的。
噢——好吧，那就发生了一件非常奇怪的事情。在发布我的答案之前，我检查了以上所有语言中所有find()和indexof()方法的文档，以确保它们都执行直接的非regex、区分大小写的搜索。所以，如果搜索是个问题，尽管任务很琐碎，我不知道该说什么。
嗯，我只检查了C++的例子，我认为你对Java示例的性能很差是对的。
@Mikenakis——直接搜索可以从了解搜索模式的长度中获益——限制搜索的范围，甚至完全不考虑在短字符串中搜索长模式的可能性。C字符串不知道它自己的长度，因此，对于每个调用，find操作将在模式上使用线性时间strlen，否则它将在不知道长度的情况下工作，并因此进行更多的工作搜索。
@你查过哪些语言？我想他们之间可能会有所不同。对于python 2.7，我的系统中编写的代码需要13.1秒，删除find调用需要0.019秒，因此字符串连接(至少在python上)是测试中不相关的部分。这可能只是因为C版本的python使用引用计数，并且可以在检测到只有一个对字符串的引用时就地进行连接。
EDCOX1×1是C++提供的构造，避免了Java中字符串连接缓慢的原因。std::string是一个可变类，与StringBuilder相同。TBH，我觉得这有点让人困惑，问题是"为什么C++慢？"，但包括Java结果，速度较慢，促使不同的人解释为什么Java结果是缓慢的。与问题无关；-)
@史蒂文314我也这么认为，但我试图寻找"a"而不是"abcdefghijklmnopqrstuvwxyz"，而且运行时间没有变化。(谈到C++样本)
@史蒂夫杰索普，你是对的，当然。
@米肯纳基斯-事实上，现在我想起来了，我会期待结果的。在"xxx…"字符串中对"abc…"的直字符串搜索简化为对"a"的直字符串搜索(从特定位置开始的每个检查在第一个字符-'A' != 'X'处失败)。这甚至引发了关于优化器有多聪明的问题——找到正确的语言和编译器，也许所有的搜索都会在编译时被优化掉(被证明是不必要的)。例如，对于haskell和ghc，您可能会发现最终的可执行文件只输出一个常量"x's length…"字符串。
@史蒂文314我不同意，如果可能的话，"暂停问题"就可以解决了。en.wikipedia.org/wiki/halting_问题。
@Mikenakis-这个程序不是所有可能的程序。haskell很可能会按照我说的做，不是通过识别特定的特殊情况，而是因为没有运行时特定的数据来阻止它在编译时执行几乎整个程序。对于更具体的优化，特定的编译器是否可能发现要搜索的字符串永远不会包含"a"？对。但这本身就不太可能，除非它可能是更普遍(但仍然不是普遍)优化的特殊情况。
@Mikenakis-虽然我不会说这会发生，尤其是在任何特定的语言中，如果你对haskell进行了深入的研究，它可能会改变你对什么是不可信的以及什么是不可信的一些假设。
好吧，我明白你的意思了，你在说"这个程序不可能都是程序"时指出了我的错误。

在nodejs中，搜索子串的算法似乎更好。你可以实现自我并尝试它。

正如SBI所提到的，测试用例由搜索操作控制。我想知道C++和JavaScript之间的文本分配速度有多快。

系统：树莓PI 2，G+4.4.3，节点V0.12.0，G++-STD= C++0X-O2 Pr.CPP

C++：770MS

无保留的C++：1196MS

javascript:2310毫秒

C++

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <iostream>
#include <string>
#include <chrono>
using namespace std;
using namespace std::chrono;

void test()
{
high_resolution_clock::time_point t1 = high_resolution_clock::now();
int x = 0;
int limit = 1024 * 1024 * 100;
string s("");
s.reserve(1024 * 1024 * 101);
for(int i=0; s.size()< limit; i++){
s +="SUPER NICE TEST TEXT";
}

high_resolution_clock::time_point t2 = high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>( t2 - t1 ).count();
cout << duration << endl;
}

int main()
{
test();
}

JavaScript

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function test()
{
var time = process.hrtime();
var x ="";
var limit = 1024 * 1024 * 100;
for(var i=0; x.length < limit; i++){
x +="SUPER NICE TEST TEXT";
}

var diff = process.hrtime(time);
console.log('benchmark took %d ms', diff[0] * 1e3 + diff[1] / 1e6 );
}

test();