转--Linux和Windows创建进程速度比较

编辑器加载中...《Unix编程艺术》倡导多进程架构，书中认为“相对独立地址空间的轻量级进程，线程是个糟糕的替代；线程是那些进程生成昂贵、IPC功能薄弱的操作系统的概念”；“基于线程的程序不仅产生普通的竞争问题，而且产生了新一类bug：时序依赖。”。确实Unix对线程确实不怎么看重，属于Unix文化范畴的Nginx、Python和Chrome都采取多进程的策略。Nginx默认情况下使用多进程模型，在生产环境下也不开启多线程（已经向淘宝网相关技术人员求证过）。Python引入GIL锁使得Python上的多线程是伪多线程，但是这大大提高了单线程程序的效率。Chrome是第一个采用多进程架构的浏览器，这种新架构不仅证明了多进程也可以拥有非常快的速度，并且具有更高的安全性。Chrome在效率和安全性上都是当前浏览器领域的翘楚。

对于Linux而言，确实没有太多必要使用多线程。主要有以下原因：
1、Linux本身采用的是轻量级进程作为线程。创建线程的开销同创建进程的开销差不多。
2、线程频繁地竞争临界资源导致效率低下。
3、Linux拥有高效的IPC功能。通过共享内存，进程可以高效共享数据。
4、多进程架构安全性更佳。

下面分别测试了Windows和Linux创建进程的速度。Unix是在不断发展过程引入多线程功能的，Windows则是作为多线程操作系统而设计。可以预见Unix创建进程的速度会比Windows快得多。

子进程序执行的代码如下：
int main(void)
{
return 0;
}

Windows测试代码如下：

?View Code C
#include
#include
#include

int main(void)
{
TCHAR cmdline[] = _T("TestPro");

PROCESS_INFORMATION pi;
STARTUPINFO si;

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );

int n = 1000;

DWORD t0 = GetTickCount();

for (int i=0; i
#include
#include

#include

#define NUM 1000

int main()
{
pid_t pid;

struct timeval begin, end;

int i;

gettimeofday(&begin, NULL);

for (i = 0; i < NUM; ++i)
{
//创建子进程
pid = fork();

if (pid == -1)
{
perror("fork");
exit(-1);
}
//子进程立即退出
else if (pid == 0)
{
if (execlp("./TestPro", NULL, NULL) < 0)
{
perror("execlp");
}
}
}

gettimeofday(&end, NULL);

printf("%dms\n", ((end.tv_sec - begin.tv_sec) * 1000000 + end.tv_usec - begin.tv_usec) / 1000);

return 0;
}
测试硬件平台为Core 2 Duo T5450 1.66GHz，1GB内存。操作系统为Windows XP SP3/Ubuntu 10.04。测试时关闭所有窗口，断开网络，只开启一个终端运行测试程序。

Windows五次运行的结果如下：
8015ms
7968ms
7968ms
8016ms
7984ms

Linux五次运行的结果如下：
291ms
281ms
292ms
281ms
277ms

Windows创建一个进程大约需8ms左右，而Linux创建一个进程大约需0.28ms，二者相差大约28倍（因为vfork减少了一些拷贝过程，因此使用vfork速度还能再快一点点）。在测试过程中，我发现Linux一个进程至多只能创建1.5万个子进程左右，否者就会出现”Resource temporarily unavailable”这个错误。系统没有限制max user processes。

下面是使用strace得到的系统调用统计结果：

?View Code TEXT
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.001750 1 1229 229 clone
0.00 0.000000 0 1 read
0.00 0.000000 0 1 write
0.00 0.000000 0 2 open
0.00 0.000000 0 2 close
0.00 0.000000 0 1 execve
0.00 0.000000 0 3 3 access
0.00 0.000000 0 1 brk
0.00 0.000000 0 2 gettimeofday
0.00 0.000000 0 1 munmap
0.00 0.000000 0 4 mprotect
0.00 0.000000 0 7 mmap2
0.00 0.000000 0 3 fstat64
0.00 0.000000 0 1 set_thread_area
------ ----------- ----------- --------- --------- ----------------
100.00 0.001750 1258 232 total
可以看到clone一共调用了1229次，其中有229次失败了。使用下面的代码测试Linux下线程的创建速度。

?View Code C
#include
#include

#include

#include

#define NUM 1000

void* callback(void* p)
{
return NULL;
}

int main()
{
pthread_t tid;

struct timeval begin, end;

int i;

int ret;

gettimeofday(&begin, NULL);

for (i = 0; i < NUM; ++i)
{
//创建线程
ret = pthread_create(&tid, NULL, (void*)callback, NULL);

if (ret == -1)
{
perror("pthread_create");
}
}

gettimeofday(&end, NULL);

printf("%dms\n", ((end.tv_sec - begin.tv_sec) * 1000000 + end.tv_usec - begin.tv_usec) / 1000);

return 0;
}
创建1000个线程仅需29ms左右，系统调用统计如下。可以发现主要的时间都花在mmap2系统调用了，clone仅仅调用380个左右，有点奇怪。

?View Code TEXT
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.000306 0 1011 620 mmap2
0.00 0.000000 0 2 read
0.00 0.000000 0 1 write
0.00 0.000000 0 3 open
0.00 0.000000 0 3 close
0.00 0.000000 0 1 execve
0.00 0.000000 0 4 4 access
0.00 0.000000 0 3 brk
0.00 0.000000 0 2 gettimeofday
0.00 0.000000 0 1 munmap
0.00 0.000000 0 380 clone
0.00 0.000000 0 1 uname
0.00 0.000000 0 385 mprotect
0.00 0.000000 0 2 rt_sigaction
0.00 0.000000 0 1 rt_sigprocmask
0.00 0.000000 0 1 getrlimit
0.00 0.000000 0 4 fstat64
0.00 0.000000 0 2 1 futex
0.00 0.000000 0 1 set_thread_area
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00 0.000306 1810 625 total
昨天同三百同学交流了下，他马上就看了glibc中相关的源代码，然后就发现当mmap2调用失败的情况下，就不会再调用clone了。这样确实吻合得很好，因为mmap2调用失败的次数（620）和clone的调用次数（380）加起来刚好是1000次。这里调用mmap2多于1000次，多出来的应该是加载动态库导致的。pthread_create调用成功返回0，否者返回一个非零值，这点同一般的系统调用和库函数调用失败返回-1不一样，所以上面代码判断返回值为-1认为调用失败是错误的。正确的情况应该是判断返回值是否为非零值。经过测试，发现在我的机器上一个进程最多只能创建300多个线程。在使用Intel Xeon E5420（64位CPU，内存8GB）的RHEL AS 4服务器上创建10000个线程都没有问题。

这篇文章参照了windows和linux进程启动速度比较，不过原文中有一些不妥之处：
1、使用System启动子程序。Linux下System函数会创建子进程，这样Linux创建的进程比Windows多了一倍。应该使用exec系统调用。
2、子程序代码偏多，使用malloc和free等库函数，干扰了实验结果。