主题：苹果已死，脸书当立？ -- 大山猫

1.longene大量借鉴了wine的源码

2.毛德操本人表示wine是在“用户空间”作兼容的，效率很难满足要求，longene正是针对这一点做出改进，更多的从内核考虑解决兼容性问题。具体请看《内核差异核内补》http://www.longene.org/techdoc/0531255001224577169.html

3.与wine效率对比：

Longene和Wine的效率测试对比分析

测试方法：

1、选定一台设备。

2、安装Wine，使用测试程序测试，得到测试结果。

3、卸载wine

4、安装Longene，使用测试程序测试，得到测试结果。

测试环境介绍：

model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz

cpu MHz: 2600.000

cache size: 2048 KB

MemTotal: 1032748 kB

MemFree: 857724 kB

Buffers: 7872 kB

Cached: 116800 kB

测试程序介绍：

TestApi针对文件读写、注册表操作，消息操作分别测试。MFC编程。

TestAll将它们整合在一起，完整地测试以上操作。MFC编程。[测试程序打包下载]

测试程序流程：

1) 根据需要测试的文件数量、注册表项数量、消息数量，创建读写进程。

2) 文件测试：

Thread1负责创建一个文件，等待Thread2读取后，再次创建

Thread2负责读取并删除文件，等待Thread1创建后，再次操作

Thread1和Thread2使用Event同步

3) 注册表测试：

Thread3负责创建一个注册表键值，等待Thread4读取后，再次创建

Thread4负责读取并删除注册表键，等待Thread3创建后，再次操作

Thread1和Thread2使用Semaphore同步

4) 消息测试：

Thread5负责发送一个消息，等待主线程接收以后，再次发送

主线程负责接收消息，等待Thread5发送后，再次操作

Thread5和主线程使用Mutex同步

5) 使用的测试函数列表：

CreateFile

WriteFile

DeleteFile

CloseFile

RegCreateKeyEx

RegSetValueEx

RegOpenKeyEx

RegCloseKey

RegQueryValueEx

RegDeleteKey

PostMessage

GetMessage

CreateEvent

SetEvent

CreateSemaphore

ReleaseSemaphore

CreateMutex

ReleaseMutex

CreateThread

CloseHandle

WaitForSingleObject

WaitForMultipleObjects

测试结果：

下面对比数据以毫秒为单位，每100次为一组，共10组。

Longene0.3:

TestApi:

WriteFile ReadFile WriteReg ReadReg MsgTest

34 7 1 1 149

23 6 1 1 157

34 6 1 1 177

44 6 1 0 197

56 6 1 0 216

65 6 1 0 253

73 7 1 0 274

86 6 1 0 297

95 6 1 0 307

91 6 0 0 313

60.10 6.20 0.90 0.30 234.00

TestAll:

FileTest Write Number 100 Read Number 100 Time 20ms

RegTest Write Number 100 Read Number 100 Time 8ms

MesTest Send Number 10000 Recieve Number 10000 Time 184ms

All Time: 207ms

Wine1.0:

TestApi:

WriteFile ReadFile WriteReg ReadReg MsgTest

44 21 7 6 900

35 20 8 7 1147

45 21 7 6 1455

59 19 7 6 1731

69 22 6 6 2007

75 20 7 6 2286

85 21 7 6 2467

97 22 8 7 2467

112 23 7 6 2434

106 20 7 8 2478

72.70 20.90 7.10 6.40 1935.20

TestAll:

FileTest Write Number 100 Read Number 100 Time 73ms

RegTest Write Number 100 Read Number 100 Time 95ms

MesTest Send Number 10000 Recieve Number 10000 Time 1222ms

All Time: 1270ms

性能提升：

WriteFile: 17.33%

ReadFile: 70.33%

WriteReg: 87.32%

ReadReg: 95.31%

MsgTest: 87.91%

Summation: 83.70%

对比分析：

以写文件操作为例(实际上读操作也是一样)，从整个过程看，Wine最低限度的操作有这么一些：

1) 客户进程通过进程间通信向服务进程发送get_handle_fd请求。注意这里至少有两次系统调用，一次是通过send_request()调用对于管道的write()，然后又通过wait_reply()调用对于管道的read()。

2) 内核调度服务进程运行。

3) 服务进程根据Handle找到目标文件在客户进程中的打开文件号，并通过进程间通信将其发送给客户进程。这里至少有三次系统调用，一次是通过send_reply()调用对于管道的write()，然后是系统调用poll()，接着又通过read_request()调用对于具体管道的read()。这里的系统调用poll()类似于select()。

4) 内核调度客户进程运行。

5) 客户进程通过系统调用dup()复制一个新的、临时的已打开文件号。

6) 然后用临时的已打开文件号调用write()。

7) 最后通过系统调用close()关闭临时的已打开文件号。

longene没有2和4过程的内核调度，因为longene去掉了WineServer。longene修改了1和3过程send_request和read_request的实现，由进程间通信改为系统调用，大大减少了通信所消耗的时间。

性能的问题在于两次进程调度。当客户进程通过IPC向服务进程发送请求时，服务进程被唤醒，内核则进行进程调度和切换。显然，用户此时希望服务进程能马上被调度运行，这样才能保证快速的响应。可是能否如愿以偿呢？这就不一定了。如果此时有个优先级更高的进程因某种原因(例如中断)而进入了就绪状态，服务进程就只好往后靠了。所以，在上列的第一和第二两个动作不一定是连续的，中间可能会有别的进程插进来。而对于桌面用户，这个优先级更高的进程得倒运行的正面效果也许感觉不到，而负面的效果却感觉到了。同样，当服务进程通过IPC回答客户进程时，客户进程也完全可能一时不能被调度运行。

文件性能测试受磁盘I/O速度的影响。longene只能节省进程调度所花费的时间，但并不能避免同是毫秒级别的磁盘读写所花费的时间。读写文件性能上的差异很好的体现了这一点。在写文件时，每次都要创建新的文件，而在读文件时，每次都是打开已有文件。所以写文件的Disk I/O比读文件的Disk I/O更多，因此性能提升比较小。

注册表性能测试可以体现出两次进程调度带来的性能差异。longene的注册表读写完成时间大概都在一毫秒之内，而进程切换都会消耗几毫秒。相比之下，注册表本身的操作所消耗的时间十分微小。

消息性能测试和注册表性能测试类似。以输入消息为例：

1) Wine需要从X11获得输入消息。

2) Wine获得输入消息后将消息放入WineServer。

3) Wine从WineServer获得输入消息。

虽然PostMessage没有和X11通信的过程，但Wine还是需要两次和WineServer通信才能获得输入消息。 longene无法避免花费和X11的通信时间，却也减少了大量的和WineServer的通信时间。

本次测试前，正好wine发布了新的1.2RC，实际测试wine1.2的结果和wine1.0几乎完全一致，可以看到wine的主要侧重点在于兼容度的提高，而由于架构的关系，在性能方面可提升的空间就很小了。