为什么在连接两个字符串时Python比C快？

Question

目前我想比较Python和C在处理字符串时的速度。我认为C应该比Python提供更好的性能；但是，我得到了完全相反的结果。在

以下是C程序：

#include <unistd.h>
#include <sys/time.h>

#define L (100*1024)

char s[L+1024];
char c[2*L+1024];

double time_diff( struct timeval et, struct timeval st )
{
    return 1e-6*((et.tv_sec - st.tv_sec)*1000000 + (et.tv_usec - st.tv_usec ));
}

int foo()
{
    strcpy(c,s);
    strcat(c+L,s);
    return 0;
}

int main()
{
    struct timeval st;
    struct timeval et;
    int i;
    //printf("s:%x\nc:%x\n", s,c);

    //printf("s=%d c=%d\n", strlen(s), strlen(c));
    memset(s, '1', L);
    //printf("s=%d c=%d\n", strlen(s), strlen(c));
    foo();
    //printf("s=%d c=%d\n", strlen(s), strlen(c));
    //s[1024*100-1]=0;

    gettimeofday(&st,NULL);
    for( i = 0 ; i < 1000; i++ ) foo();
    gettimeofday(&et,NULL);

    printf("%f\n", time_diff(et,st));
    return 0;
}

这是Python的一个：

^{pr2}$

我得到的是：

root@xkqeacwf:~/lab/wfaster# python cp100k.py 
0.027932882309
root@xkqeacwf:~/lab/wfaster# gcc cp100k.c
root@xkqeacwf:~/lab/wfaster# ./a.out 
0.061820

有道理吗？还是我犯了什么愚蠢的错误？在

Answer 1

我认为这是因为Python字符串不是以null结尾的。在

在Python中，字符串长度存储在字符串旁边，允许它在连接字符串时跳过strcat（）使用的隐式strlen（）。在

原因可能是字符串连接是直接用C实现的。在

编辑：好吧，现在我实际查看了C代码，发现它使用静态缓冲区，我也很困惑，因为我不明白Python如何避免动态分配，而动态分配应该慢得多。。。在

Answer 2

累积的意见（主要是我的意见）转化为答案：

• 如果使用字符串长度的知识并使用memmove()或{}代替strcpy()和{}，会发生什么情况？（我注意到strcat()可以被strcpy()替换，结果没有差别——检查时间可能很有趣。）另外，您没有包括<string.h>（或<stdio.h>），因此您错过了<string.h>可能提供的任何优化！在

Marcus: Yes, memmove() is faster than strcpy() and faster than Python, but why? Does memmove() do a word-width copy at a time?

• 是的；在一台64位机器上，它可以一次移动64位数据，而不是一次移动8位；一台32位机器，可能一次移动32位。它在每次迭代（count）上也只有一个更简单的测试，而不是（count或是null byte'）“这是空字节吗”。在

Marcus: But memmove() is still working well even after I make L=L-13, and sizeof(s) gives out L+1024-13. My machine has a sizeof(int)==4.

• memmove()的代码是高度优化的汇编程序，可能是内联的（没有函数调用开销，但是对于100KiB的数据，函数调用开销最小）。好处是从更大的移动和更简单的循环条件。在

Marcus: So does Python use memmove() as well, or something magic?

• 我没有看过Python源代码，但实际上可以肯定的是，它跟踪字符串的长度（它们是以null结尾的，但是Python总是知道字符串的活动部分有多长）。知道了这个长度，Python就可以使用memmove()或{}（区别在于，即使源和目标重叠，memcpy()也可以正常工作；memcpy()如果它们重叠，就没有义务正确工作）。相对而言，他们不太可能有比memmove/memcpy更快的东西。在

---

我修改了C代码以在我的机器上生成更稳定的计时（macosx10.7.4，8gib1333mhz RAM，2.3ghz英特尔酷睿i7，gcc4.7.1），并比较了strcpy()和{}vsmemcpy()vsmemmove()。请注意，我将循环计数从1000增加到10000，以提高计时的稳定性，并且我将整个测试（所有三种机制）重复10次。可以说，定时循环计数应该再增加5-10倍，以便计时超过一秒钟。在

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/time.h>

#define L (100*1024)

char s[L+1024];
char c[2*L+1024];

static double time_diff( struct timeval et, struct timeval st )
{
    return 1e-6*((et.tv_sec - st.tv_sec)*1000000 + (et.tv_usec - st.tv_usec ));
}

static int foo(void)
{
    strcpy(c,s);
    strcat(c+L,s);
    return 0;
}

static int bar(void)
{
    memcpy(c + 0, s, L);
    memcpy(c + L, s, L);
    return 0;
}

static int baz(void)
{
    memmove(c + 0, s, L);
    memmove(c + L, s, L);
    return 0;
}

static void timer(void)
{
    struct timeval st;
    struct timeval et;
    int i;

    memset(s, '1', L);
    foo();

    gettimeofday(&st,NULL);
    for( i = 0 ; i < 10000; i++ )
        foo();
    gettimeofday(&et,NULL);
    printf("foo: %f\n", time_diff(et,st));

    gettimeofday(&st,NULL);
    for( i = 0 ; i < 10000; i++ )
        bar();
    gettimeofday(&et,NULL);
    printf("bar: %f\n", time_diff(et,st));

    gettimeofday(&st,NULL);
    for( i = 0 ; i < 10000; i++ )
        baz();
    gettimeofday(&et,NULL);
    printf("baz: %f\n", time_diff(et,st));
}

int main(void)
{
    for (int i = 0; i < 10; i++)
        timer();
    return 0;
}

编译时不会发出警告：

^{pr2}$

我得到的时机是：

foo: 1.781506
bar: 0.155201
baz: 0.144501
foo: 1.276882
bar: 0.187883
baz: 0.191538
foo: 1.090962
bar: 0.179188
baz: 0.183671
foo: 1.898331
bar: 0.142374
baz: 0.140329
foo: 1.516326
bar: 0.146018
baz: 0.144458
foo: 1.245074
bar: 0.180004
baz: 0.181697
foo: 1.635782
bar: 0.136308
baz: 0.139375
foo: 1.542530
bar: 0.138344
baz: 0.136546
foo: 1.646373
bar: 0.185739
baz: 0.194672
foo: 1.284208
bar: 0.145161
baz: 0.205196

奇怪的是，如果我忽略了“no warnings”而忽略了<string.h>和{}头，就像在最初发布的代码中一样，我得到的计时是：

foo: 1.432378
bar: 0.123245
baz: 0.120716
foo: 1.149614
bar: 0.186661
baz: 0.204024
foo: 1.529690
bar: 0.104873
baz: 0.105964
foo: 1.356727
bar: 0.150993
baz: 0.135393
foo: 0.945457
bar: 0.173606
baz: 0.170719
foo: 1.768005
bar: 0.136830
baz: 0.124262
foo: 1.457069
bar: 0.130019
baz: 0.126566
foo: 1.084092
bar: 0.173160
baz: 0.189040
foo: 1.742892
bar: 0.120824
baz: 0.124772
foo: 1.465636
bar: 0.136625
baz: 0.139923

仔细观察这些结果，它似乎比“更干净”的代码要快，尽管我没有对这两组数据进行学生t检验，而且计时具有非常大的可变性（但我确实有类似Boinc在后台运行8个进程的东西）。在代码的早期版本中，效果似乎更为明显，当时只测试了strcpy()和{}。如果这是真的效果，我无法解释！在

由mvds跟进

既然问题已经结束了，我就不能正确回答了。在Mac电脑上，几乎什么都不做，我得到了以下时间安排：

（带标题）

foo: 1.694667 bar: 0.300041 baz: 0.301693
foo: 1.696361 bar: 0.305267 baz: 0.298918
foo: 1.708898 bar: 0.299006 baz: 0.299327
foo: 1.696909 bar: 0.299919 baz: 0.300499
foo: 1.696582 bar: 0.300021 baz: 0.299775

（无标题，忽略警告）

foo: 1.185880 bar: 0.300287 baz: 0.300483
foo: 1.120522 bar: 0.299585 baz: 0.301144
foo: 1.122017 bar: 0.299476 baz: 0.299724
foo: 1.124904 bar: 0.301635 baz: 0.300230
foo: 1.120719 bar: 0.300118 baz: 0.299673

预处理器输出（-E标志）显示，包含头会将strcpy转换为如下内置调用：

((__builtin_object_size (c, 0) != (size_t) -1) ? __builtin___strcpy_chk (c, s, __builtin_object_size (c, 2 > 1)) : __inline_strcpy_chk (c, s));
((__builtin_object_size (c+(100*1024), 0) != (size_t) -1) ? __builtin___strcat_chk (c+(100*1024), s, __builtin_object_size (c+(100*1024), 2 > 1)) : __inline_strcat_chk (c+(100*1024), s));

因此strcpy的libc版本的性能优于gcc内置版本。（使用gdb可以很容易地验证strcpy上的断点在strcpy()调用中确实没有中断，如果包含头的话）

在Linux（Debian5.0.9，amd64）上，这些差异似乎可以忽略不计。生成的程序集（-S标志）只在include携带的调试信息上有所不同。在