评论

#sokvsolun 发表于2006-08-12 15:59:00  IP: 211.100.21.*

TrackBack来自《shiyan》：

yiban

#hefei2 发表于2006-08-07 21:33:00  IP: 222.172.138.*

附带一提，据Twisted文档宣称，Conch的运行时性能并不逊色于OpenSSH。在同一台计算机上，OpenSSH每秒钟可接纳3个连接，传输速度7.4MB/s。而纯Python实现的Conch每秒钟可接纳8个连接，传输速度3MB/s。经过Psyco编译优化后，每秒钟可接纳11个连接，传输速度8.1MB/s。


这是不是说python的性能还要高于c的性能？还是说Conch的性能高于OpenSSH的性能？总觉得解释型的语言不大可能超过编译型的语言吧。
不太明白，还请大哥们指点。

#myan 发表于2006-08-07 22:35:00  IP: 219.236.52.*

to hefei2:
好几个朋友看了这篇blog，对于开发效能都不是很在意，反而是对于最后这个运行时性能的比较非常感兴趣。然而我的看法是，不要过于看重这个评测结果。

首先，这是Twisted自己的文档，尽管我相信评测者不会故意伪造试验条件贬低OpenSSH，但是没有尽心优化，却是非常可能的。

其次，经Psyco编译之后，Conch实际上是一个native code program。你说“解释型语言不大可能超过编译型语言”，但这里是两个机器码程序之间的比较。

第三，请注意当你用C语言写一个高层应用程序的时候，你的思路不得不在高级设计和底层细节之间不断跳越，很难把握好，形成真正优化的设计。而你做的很多事情是在重复Python等高级语言已经内建并且经过极度优化的工作，用Python写代码，可以集中力量思考高级设计问题，所以比较容易形成良好的设计。很早有人就发现，用C语言进行正则表达式分析还不如Perl快，这并不是语言本身的比较，而是当开发者能力相当时，采用高级语言能够比较容易地得到优化的整体设计。

第四，我相信，如果设计上水平相当，C肯定跑得比Python快十倍。问题在于，一旦程序规模达到一定程度，完成一个与对应Python程序在设计上水平相当的C程序，所付出的代价恐怕要多出几十倍。

#tonny1982 发表于2006-08-07 23:44:00  IP: 61.135.146.*

开发效率和运行效率是一个很难来平衡的事情
关键是要看你的需求,如果你要做一个压力特别的忘了服务的话,我相信C是一个比较好的选择,当然如果你的项目马上要上线,而且刚刚开始那种压力不会一下子变的很大,ok,Python PHP...但是你要随时准备好重新用C重写你的核心代码
注意是核心,不一定是全部,曾经看到这样一句话觉得很有道理:
80%的瓶颈出现在20%的代码,那么你只要重写这20%就Ok了,当然这要得益于动态语言很好的粘性,Python和PHP都具备这种能力

另外我对文章中的几个数据比较不以为然,这些东西跟象是广告
再从另外一个角度将OpenSSH运行效率不要只能怪代码烂(只是一种假设:P)

#tonny1982 发表于2006-08-07 23:47:00  IP: 61.135.146.*

开发效率和运行效率是一个很难来平衡的事情
关键是要看你的需求,如果你要做一个压力特别的忘了服务的话,我相信C是一个比较好的选择,当然如果你的项目马上要上线,而且刚刚开始那种压力不会一下子变的很大,ok,Python PHP...但是你要随时准备好重新用C重写你的核心代码
注意是核心,不一定是全部,曾经看到这样一句话觉得很有道理:
80%的瓶颈出现在20%的代码,那么你只要重写这20%就Ok了,当然这要得益于动态语言很好的粘性,Python和PHP都具备这种能力

另外我对文章中的几个数据比较不以为然,这些东西跟象是广告
再从另外一个角度将OpenSSH运行效率不要只能怪代码烂(只是一种假设:P)

#TripleX 发表于2006-08-08 01:00:00  IP: 222.128.6.*

如果我的猜测没错的话 象OpenSSH这样的接纳连接的速度取决于
1 RSA和md5算法的速度
2 是否打开了反解功能
其中第二点影响尤其大 有空我自己测试一下再说 呵呵
反正包子的肉都不在褶子里 这种带加密的程序速度慢都不再加密之外的部分

#TripleX 发表于2006-08-08 01:04:00  IP: 222.128.6.*

看了一下 Conch用的加密库不是OpenSSL的libcrypto 是自己带的 我的debian系统上有如下动态库
/usr/lib/python2.4
/usr/lib/python2.4/site-packages
/usr/lib/python2.4/site-packages/Crypto
/usr/lib/python2.4/site-packages/Crypto/Hash
/usr/lib/python2.4/site-packages/Crypto/Hash/MD2.so
/usr/lib/python2.4/site-packages/Crypto/Hash/MD4.so
/usr/lib/python2.4/site-packages/Crypto/Hash/SHA256.so
/usr/lib/python2.4/site-packages/Crypto/Cipher
/usr/lib/python2.4/site-packages/Crypto/Cipher/Blowfish.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/XOR.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/ARC2.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/ARC4.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/CAST.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/DES3.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/AES.so
/usr/lib/python2.4/site-packages/Crypto/Cipher/DES.so
/usr/lib/python2.4/site-packages/Crypto/PublicKey
/usr/lib/python2.4/site-packages/Crypto/PublicKey/_fastmath.so
速度肯定都从这些库里来 看来这些库写得比OpenSSL要稍快一些

#TripleX 发表于2006-08-08 01:05:00  IP: 222.128.6.*

什么时候有空单独写一些程序 对比python-crypto和openssl libcrypto的速度 估计原因就出来了

#redsea 发表于2006-08-08 01:30:00  IP: 219.137.203.*

不管怎么说, python 拥有很多良好的资源, 一些cpu 消耗大的计算也有 .so 的代码, 写很多程序都不觉得慢.

我们现在就是用 C++/C + python.

上次一个朋友想开发web, 想快速开发, 又想以后万一规模大了的时候, 也能够支持得住.

我建议他目前用python 的 turbogears 框架(当然数据库部分不能选sqlobject , 必须用sqlalchemy), 以后万一规模上来了, 那么能够静态化的网页就静态化,无法静态化的少数网页, 用c写lighttpd 的plugin就好; form 提交处理继续用写好的代码即可, 这部分不是主要消耗, 即使负荷不起,用linux virtual server 均衡到几台机器上也很简单, 不会多很多机器.

这样, 框架简单(比起java 的方案), 开发快, 以后也有提升空间.

#TripleX 发表于2006-08-08 01:48:00  IP: 222.128.6.*

其实python写很多程序都不慢 呵呵 按照代码一行一行比 python当然比c慢 但是很多情况下 这些都只是包子的褶 肉都不在这个上 :-)

#myan 发表于2006-08-08 07:32:00  IP: 219.236.52.*

to TripleX:
非常感谢。

请注意是OpenSSH，不是OpenSSL。

#TripleX 发表于2006-08-08 00:53:00  IP: 222.128.6.*

其实这个事情特别简单 因为ssh的速度限制主要在加密/解密的部分 而那部分一般都是用汇编写的(c库) 如果测试出来速度有明显差别 那么表明其余部分的代码速度和加密一样慢 我的天 那得慢多少个数量级阿.....
想起来以前有一个公司把quakeII用java重写了 发现速度和c的版本差不多 我下载了一个回来试 在我的机器上c的版本快了不少 !! 看了一下测试机器的配置 发现他们用2G的AMD cpu配TNT M64显卡 瓶颈在显卡上~~ 而我的机器显卡是Radeon7200 cpu却只有800MHz CPU是瓶颈 所以速度差别就显现出来了 用OpenGL的Performance工具看也看到了差别 用c写的版本有50%的时间是处理器在等显卡 而java的版本只有20%多一点的时间是处理器等待显卡 很明显c的版本差不多要快一倍 :-)

#myan 发表于2006-08-08 07:48:00  IP: 219.236.52.*

to redsea:
介绍一下你自己的Python体验嘛 :-)

Python在动态语言里并不是以快闻名的，其实它的设计思想主要是追求高层次上的简单优雅，在性能上不仅不是最快的，而且很多年以来一直有“最慢”的恶名。可是放在实践中感觉完全不是那么一回事，大家觉得开发效率和运行效率都令人满意。我想主要原因就是Python的资源丰富而且质量很高，当性能遇到瓶颈的时候，有人会去开发extension。这样一来就形成了良好的平衡。

在这方面我自己是有体验的，在简单的小规模问题上，我可以轻易用C/C++写出效率8-10倍于Python的程序，所花费的开发时间大致也是8 -10倍。但是程序规模一大，两方面的比率都会发生非常不利于C/C++的变化：运行效率优势降低，而开发时间比开始恶性膨胀。尤其是在没有基础库的支持下用C写程序时，如果代码质量要求比较高，那么开发效率是非常低的。

#TripleX 发表于2006-08-08 09:49:00  IP: 222.128.6.*

To myan:
OpenSSH用的libcrypto就是OpenSSL项目提供的libcrypto加密库
#ldd /usr/sbin/sshd
linux-gate.so.1 => (0xffffe000)
libwrap.so.0 => /lib/libwrap.so.0 (0xa7fc1000)
libpam.so.0 => /lib/libpam.so.0 (0xa7fb9000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xa7fb4000)
libresolv.so.2 => /lib/tls/libresolv.so.2 (0xa7fa1000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xa7e67000)

#TripleX 发表于2006-08-08 09:51:00  IP: 222.128.6.*

To myan:
OpenSSH用的libcrypto就是OpenSSL项目提供的libcrypto加密库
#ldd /usr/sbin/sshd
linux-gate.so.1 => (0xffffe000)
libwrap.so.0 => /lib/libwrap.so.0 (0xa7fc1000)
libpam.so.0 => /lib/libpam.so.0 (0xa7fb9000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xa7fb4000)
libresolv.so.2 => /lib/tls/libresolv.so.2 (0xa7fa1000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xa7e67000)

#TripleX 发表于2006-08-08 10:53:00  IP: 222.128.6.*

python操作二进制数据还是很麻烦的 幸亏有twisted这样的库 要不然写一个基于二进制的协议得累死 呵呵

#analyst 发表于2006-08-08 12:28:00  IP: 222.70.126.*

这样的比较是不公平的，前面也说了，Conch本身架构在Twisted之上，Twisted本身也是具有6万行代码规模的项目。开发一个Twisted需要多少人年呢？而OpenSSH是直接基于Unix系统服务开始构建的。
做成熟应用，python有很多成熟的库可以用，开发效率当然要比从头构建要快的多。但是如果做新的应用，没有成熟的库可以用，你免不了还得用C写extension，写extension的时候还得考虑更多的通用性，性能之类的问题，这样的开发效率跟直接用C差不了多少。

#ywchen2000 发表于2006-08-08 12:38:00  IP: 218.107.29.*

myan
我现在就是在用C++从写PYTHON写代码，抓狂中

#redsea 发表于2006-08-08 13:05:00  IP: 218.19.157.*

我用python 的体验?
应该没有什么特别的吧.

1. 用python 的时候, 感觉是花在 语言,库使用方面的时间大大降低, 主要的时间花在问题域上了.
这一方面应该是python语言本身比C/C++ 之类的就更简单, 各种基本支撑措施都齐全易学(log, serialization, rpc, db,regex 等等) 且跨平台, 很少需要费心在这些方面 -- 不像C/C++, 如果在某个领域没有积累, 可能需要自己写上不少底层支撑代码, 跨平台代码之类的, 换个项目这些方面的选择变了, 又要重新学; pythonic 原则设计的各种库很齐全,使用也很容易.

另一方面, 选择了python 做开发的时候, 也就更有了自觉, 优化是整体设计级别, 语句级别没有太多搞头.

2. 编写, 调试循环快
python 写同样的东西, 语句比c 少, 没有编译时间; 由于是解释型的, 一些功能较独立的函数直接可以在解释器里面测试是否工作正常.
这些特点造成编写, 调试周期短.

3. 字符串操作轻松
编程工作里面, 有很多的时候要进行字符串操作, 这些方面, 脚本语言都易用而且效率不差.
例如 python % 算符的键值替换方法, 用来构造 sql 的时候, 写起来方便不容易错, 读起来也直观 -- 如果python 字节码编译器不笨的话, 编译结果的运行效率也应该比printf 高.


说到C++, 多扯几句. C++ STL 库, 强大但丑陋, 写出来就是不准备让人看的, 读这些代码吃力不讨好, 和著名的只读语言forth, 难读语言perl 也没有什么区别, 不但初学者无法从中学习编程, 我这种已经入门了的人也很难读. 当初读iostream, 想看看其中某个特性做得如何的时候 -- 心里怨恨, 不知道 STL 算不算 lib 开发者友好, 但肯定是lib 使用者不友好.

#charon 发表于2006-08-08 11:58:00  IP: 210.52.78.*

/*很早有人就发现，用C语言进行正则表达式分析还不如Perl快，这并不是语言本身的比较，而是当开发者能力相当时，采用高级语言能够比较容易地得到优化的整体设计。
*/

严重同意！！！

#redsea 发表于2006-08-08 16:03:00  IP: 124.248.72.*

to analyst
>这样的比较是不公平的，前面也说了

我没有觉得这种比较有什么不公平, 语言之间的比较当然不应该只是比较语言本身, 还应该加上该语言中成熟的库一齐比较. 如果 Java 和 C++ 一样, 标准库那么少, 还会那么受欢迎吗 ?

twisted 是一个成熟的库, 作为python 的一个基本装备并无不可.

C++ 网络方面也有不少的库, 例如 ACE, 但是种种原因, 开发人员进行开发的时候 不一定选择这些库. 这可能是和具体应用场合有关的业务领域相关问题, 也可能是和 C++, 目标库特点的技术选择问题. 如果属于后者, 是属于语言/库的缺点造成的.

#Gawain 发表于2006-08-08 18:29:00  IP: 10.218.12.*

这样的方法对C很是不公，这样的话是不是可以搭上AppleScript.
因为在C中的实现只要一行或数行便可以完成AppleScript或python在2倍或3倍以上的代码量。

#analyst 发表于2006-08-08 19:03:00  IP: 222.70.125.*

争论公平不公平到也是没什么意义，我一向主张实用主义，哪个好用就用哪个。我只是对1:4:10这样的数据颇不以为然，因为没有什么代表性。
另外redsea 对 C++ STL 的认识与事实恰恰相反，STL 是用起来简单实现起来难，没有哪个人用STL的时候还要去读STL源代码的，除非是以研究为目的。

#redsea 发表于2006-08-08 20:21:00  IP: 218.19.157.*

to analyst:
既然用到 C++, 我就会对性能和内存占用考虑得比较多, 否则我就不会用C++了, 我会用python 或者 delphi, 我并不是 C++ 狂热者 --- 其实我不是编程爱好者, 能够不写代码, 我是不想写的, 能够不研究某些技术, 我是不想研究的.

要关注性能和内存占用, 需要准备怎样的 allocator 给它才能长久运行不会产生内存碎片, 等等, 我就只好阅读源代码了.

举个例子, STL list 的实现, 如果我用来放一个指针, 以便避免昂贵的对象构造和复制, 那么我当然要知道它内部是每个entry 都申请一次内存, 还是更聪明, 内部申请大块自己管理. 如果它每次都申请, 我用heap 方式的allocator 就会有很大的代价 -- heap 管理的overhead, alignment(现在缺省8byte) 的overhead, 使得每个指针最后耗费的内存可能是很多倍, 而且申请到的内存在空间中也不连续.

#狗见愁 发表于2006-08-08 22:02:00  IP: 222.90.74.*

C++给了人造轮子的可能，就有人非要舍弃现有的轮子不用，去重新发明轮子，然后说C++如何如何麻烦；

C++就像是最好的登山装备，最好的登山者唯一的选择，但最好的登山者想要征服的也是最危险的山峰。

#shhgs 发表于2006-08-09 07:12:00  IP: 70.27.117.*

十年 发表于2006-08-08 22:23:00 IP: 218.18.19.*

我自己认为Python的运行效率高是与C语言分不开的。要知道Python的很多库都是用C写的，然后套上Python的解释器执行罢了。所以说他们之间的比较确实没有多大意义。比去比来，结果是比较“高手的C代码”与“低手的C代码”之间的比较。毕竟Python的C代码是经过实践考验的，值得信赖，但一般的C程序员不一定写出那么高的C代码。

严重同意！！

#analyst 发表于2006-08-08 22:22:00  IP: 211.161.210.*

呵呵，你这就钻牛角尖了，至少我写这么多年C++从来没有自定义过allocator。STL原本已经有不错的效率，我为什么还要去担心这个？难道你写python的时候会对效率提心吊胆吗？一个成熟的开发者是不会去盲目优化程序的，更不会刻意的玩弄技巧。当然反过来说，万一如果某个STL容器确实构成了性能瓶颈，那我干吗还要在STL里面死磕呢？自己实现一个简单的容器不就得了，自己写的最有把握。

#十年 发表于2006-08-08 22:23:00  IP: 218.18.19.*

我自己认为Python的运行效率高是与C语言分不开的。要知道Python的很多库都是用C写的，然后套上Python的解释器执行罢了。所以说他们之间的比较确实没有多大意义。比去比来，结果是比较“高手的C代码”与“低手的C代码”之间的比较。毕竟Python的C代码是经过实践考验的，值得信赖，但一般的C程序员不一定写出那么高的C代码。

#Ishou 发表于2006-08-09 12:03:00  IP: 202.156.165.*

这种比较怎么没有意义？起码让您认识到，脚本语言写的程序的运作效能 在很多时候与 纯C/C++的程序 并没有多大差别，甚至由于脚本核心/库程序的优化， 脚本程序的运行效率更好！人们应该改变“脚本语言慢”的观念！ 脚本语言“慢”在程序码需要“解释”方面，如果需要“解释”程序码不长，这里的“解释”所消耗的时间是微不足道的。
另外，对于Windows中的一步操作， 程序消耗1毫秒 与消耗0.01毫秒是没有本质差别的，尽管后者比前者快了99倍之巨！


脚本语言在组合现有已知的功能方面的灵活性、简洁性大大超过C/C++程序语言，但是在处理未知复杂的问题时，往往需要让脚本运行很多程序码，会大大降低脚本语言的运效率，通过脚本语言提供的C/C++接口，把这些复杂的东西用C/C++程序实现，做成脚本语言简便调用的库函数之类，脚本语言的程序可以获得很好的 开发和运行效率。 如果没有C/C++语言做后盾，纯粹用脚本语言开发会有瓶颈。
总之， 脚本语言 ＋ C/C++语言 可以获得很好的 开发和运行效果！

#Ishou 发表于2006-08-09 12:08:00  IP: 202.156.165.*

这种比较怎么没有意义？起码让您认识到，脚本语言写的程序的运作效能 在很多时候与 纯C/C++的程序 并没有多大差别，甚至由于脚本核心/库程序的优化， 脚本程序的运行效率更好！人们应该改变“脚本语言慢”的观念！ 脚本语言“慢”在程序码需要“解释”方面，如果需要“解释”程序码不长，这里的“解释”所消耗的时间是微不足道的。
另外，对于Windows中的一步操作， 程序消耗1毫秒 与消耗0.01毫秒是没有本质差别的，尽管后者比前者快了99倍之巨！


脚本语言在组合现有已知的功能方面的灵活性、简洁性大大超过C/C++程序语言，但是在处理未知复杂的问题时，往往需要让脚本运行很多程序码，会大大降低脚本语言的运效率，通过脚本语言提供的C/C++接口，把这些复杂的东西用C/C++程序实现，做成脚本语言简便调用的库函数之类，脚本语言的程序可以获得很好的 开发和运行效率。 如果没有C/C++语言做后盾，纯粹用脚本语言开发会有瓶颈。
总之， 脚本语言 ＋ C/C++语言 可以获得很好的 开发和运行效果！

#Wayne 发表于2006-08-09 12:20:00  IP: 218.75.242.*

我们现在做的项目就是用c++和python，python跨平台很好用，而且开发速度很快。我很喜欢 python:)

#Ishou 发表于2006-08-09 12:55:00  IP: 202.156.165.*

用 脚本语言 ＋ C/C++语言 做项目，尤其是大的项目，该脚本语言往往自然成为该项目进行 二次开发的脚本语言， 可以显著增强/拓展该 项目的功能！
用C/C++搞一个适合本项目的二次开发语言，其难道往往比项目本身要大得多！

#愚公 发表于2006-08-09 22:36:00  IP: 58.100.161.*

愚蠢的，毫无意义的比较。

#redsea 发表于2006-08-12 11:27:00  IP: 219.136.215.*

今天看了 boost.serialization 在 vs 2005 下面生成的二进制码. 已经开了优化, 尽量 inline, 但是生成的代码还是无比冗长, 我想不会比 python pickle 的代码高效很多.

boost.serialzation 里面又是用map, 又是用tree 的,似乎完全不考虑效率的.
加上 boost.filesystem, 已经看到 boost 里面两个基本不考虑效率的库了.

#aaa 发表于2006-08-12 11:53:00  IP: 222.35.78.*

从这一个小项目能说明个p啊。
太无聊了吧？
还有那么多人跟风。
可以肯定得说c得开发效率肯定低于Java,这个连入门人都知道，还在这里讨论。

#问问 发表于2006-08-14 00:41:00  IP: 222.18.1.*

我还在上学，敢问：现在国内真在用python的公司多嘛？
从书籍市场看，好像很少。

#sungan 发表于2006-08-14 08:57:00  IP: 159.226.251.*

to redsea
我觉得你好像有些概念不是很清楚，你所说的“生成的二进制码”就是指生成的机器码把，开速度优化，尽量inline都是会使最终的代码量增加的方式，你使用了这些选项编译程序，然后抱怨生成的代码冗长，我觉得不大合适。我曾经使用intel编译器设置了执行速度最快的编译选项，要比vs2005编译器编译出来的代码量大了不只两倍。你认为intel比微软更不了解他的cpu吗？为了提高速度，大多数时候就要在空间上做出牺牲，代码量大不代表效率低，这是最基本的道理。
map和tree都是很有效率的，关键看你用来做什么，当然如果你非要用他们来完成一个用array都可以解决的问题，我就无话可说了

#PP 发表于2006-08-14 17:35:00  IP: 222.90.66.*

to 问问 :

我们在用，去年的后台逻辑都是用Python写的！

#PP 发表于2006-08-14 17:30:00  IP: 222.90.66.*

to 问问 :

我们在用，去年的后台逻辑都是用Python写的！

#abc 发表于2006-08-15 10:30:00  IP:

白痴级的比较。openssh的功能另外两个拍马也追不上。

#redsea 发表于2006-08-16 13:23:00  IP: 219.136.130.*

to sungan:
是我识lib 不明, 还想用serialization 这种库省掉我写object -> network packet, network packet ->object 的转化代码.

我只需要转换到简单的text 即可, 但我看到一个 int 转换到 text 的代码如此复杂, 里面又是map, 又是tree 的时候, 生成了无数的二进制吗, 我只好感叹, 通用的多功能library, 就是只能做一些很普通的事情, 例如保存配置之类的, 别的就不要指望了.

#sungan 发表于2006-08-16 14:22:00  IP: 159.226.251.*

我对序列化这种东西了解不多，不敢妄言。但是仅想想动态存储和恢复对像的复杂过程就头疼不已。像你说的这种功能用序列化的确没啥必要。
同时我也很困惑究竟什么才是真正需要使用序列化的时机
在JAVA中序列化似乎也是一个很重要的组成部分，MFC中也提供了序列化的功能，可是为啥我就体会不到序列化的妙用?

#ZXEOC 发表于2006-09-19 14:19:00  IP: 61.51.104.*

to redsea:
工具都是有适用范围的，如果只是简单的int到text，干吗非得用序列化？基本库里不是有itoa，就好像我只想开啤酒瓶，那只要拿个瓶起子就好了，用不着非花几百块买把瑞士军刀，沉甸甸的不说，弄不好还容易扎手

#wooyon 发表于2007-01-02 11:53:23  IP: 58.53.76.*

to myan:
对C与Java的评价相对合理,从它们编译本质上看,二者几乎是在同一个级别,即几乎都是从无到有的实现;反而对Python待脚本语言则是高估,而且极其严重.你也知道
"Conch本身架构在Twisted之上，后者是一个高层的网络开发框架，本身也是具有6万行代码规模的项目。Conch的高效能很大程度上受惠于此。"?
因此授予期"10"的比重中极不合理的.至于对开发的工程量相关的比较,我认为只能作为这个比例来源的分析参考,不足以得出三者的这个比例

#realdreamer 发表于2007-05-11 22:02:17  IP: 58.31.17.*

倒死, 这种数据能做互相比较吗.

C 语言算是三语言中最新实现的, 那是基础, 我就不信开发其他语言版本的一点都没做参考. 人也是越来越聪明, 积累越来越多. 这种评价方法, 一点不科学.

#realdreamer 发表于2007-05-11 22:04:38  IP: 58.31.17.*

序列化这玩意,我看就是好语言之人硬想出来的东西.
不要越搞越复杂了. 这不是万能的