该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-09-18
由于本论坛不支持语法着色及格式化,只贴上部分内容 详情请进入我的博客,不足之处还望各位同学多多指正:http://blog.csdn.net/Rails/archive/2006/09/17/1232993.aspx ) 目 标:从一个文件中选出使用频率最多的30个单词 Ruby代码: def test count = Hash.new(0) for line in open("test.txt") for word in line.split count[word] += 1 end end p count.to_a.sort_by{|x| x[1]}[-30, 30].reverse end if __FILE__ == $0 t1 = Time.now test puts t2 = Time.now - t1 end Python代码: from time import time from operator import itemgetter def test(): count = {} for line in open("test.txt"): for word in line.split(): count[word] = 1 + count.get(word, 0) print sorted(count.iteritems(), key=itemgetter(1), reverse=True)[0:30] if __name__ == "__main__": t1 = time() test() print time()-t1 输出为: [('the', 113450), ('of', 65380), ('to', 54960), ('and', 46110), ('a', 35090), ('in', 29400), ('that', 25110), ('was', 24390), ('his', 23460), ('he', 19130), ('as', 18600), ('had', 13630), ('is', 13590), ('it', 12730), ('not', 12310), ('be', 12080), ('for', 11250), ('on', 10750), ('with', 10680), ('this', 10450), ('by', 8780), ('The', 8510), ('I', 8400), ('have', 8360), ('but', 8060), ('which', 7960), ('all', 7870), ('their', 7490), ('so', 7470), ('at', 7400)] 现在两个程序的时间和内存消耗分别为(括号中为psyco/yarv的分值): ruby1.8.4@win32: 7.3s, 5M ruby1.8.5@cygwin: 6.45s, 5M(6.04s, 5M) ruby1.8.5@ubuntu: 4.25s, 3.2M(4.11s, 3.2M) py2.5@win32: 2.34s, 3M(1.54s, 5M) py2.5@cygwin: 2.45s, 4M(1.74s, 6M) py2.5@ubuntu: 2.25s, 1.7M(1.34s,1.8M) 注意:尽管Ruby的内存占用量只有原来的1/20,但速度也明显慢了下来;而Python内存占用一样骤减,速度也随之提升。。 更新@2006.09.17, 22:50 这两个程序最后打印结果的那行都还可以稍稍作下改进: Ruby的可以改为: p count.to_a.sort_by{|x| -x[1]}[0, 30] Python的可以改用2.5版最新引入的nlargest()函数(新发现的很棒的东东,只是Ruby目前还未包含类似的函数,Ruby1.9也没看到,只有一个max_by): print nlargest(30, count.iteritems(), key=itemgetter(1)) # from heapq import nlargest 更新@2006.09.18, 08:25 新增Ubuntu下的分值 结论: Python经过这几年的发展,进步真的很大,不管是在性能还是标准库的扩充方面。而Ruby在这方面却令人有点失望,有时运行速度只及Python的1/3,YARV也形同虚设。值得注意的是两者在Ubuntu下的表现都不错,尤其是Ruby,有显著提升。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-09-18
thanks 楼主的详细代码和细致比较。
另外,这里还有一个讨论。 http://www.iteye.com/post/138935 charon 写道 cookoo 写道 huangyi,ironpython编译成什么样的IL代码?因为jython虽然编译成字节码但实际还是内嵌一个python解释器,所以虽然有VM提供JIT但速度和cpython还是在仲伯之间。C#编译出的IL代码速度一般是cpython的10-20倍左右,ironpython有cpython的5倍就非常不得了。
我记得原文说是很多情况下ironpython性能优于cpython,这个很多就很难界定了。就和前段时间有帖子说python写的程序比C写的快一样 如果是计算密集型,还是shootout的结果比较客观一点,毕竟大家都是python语法,就不存在是不是贴切实现的问题了 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=python&lang2=iron 至于典型情况下如何,谁也说不清楚。除非用这两种实现对所有的标准库和知名的第三方库和软件进行benchmark,这个就不太可能了 里面提到了一个shootout site,专门做各种语言的速度评测。 搜索language performance,一般也会遇到这个site。 以前看到过的印象,用户好像可以把自己的测试结果提交给那个网站。 -------------------- 有一个题外的问题。 http://www.iteye.com/post/138935 这个link走到了页面的中间,定位到这个帖子的书签上。这个是如何做到的? 我只知道需要一个anchor http://www.iteye.com/post/138935#138935 难道有另外的通知browser哪里有书签的的HTML Meta or Element ? ---------------------- thanks 楼下 ReadOnly 的解答。 原来是js的作用。 |
|
返回顶楼 | |
发表时间:2006-09-18
有一个问题.
能够把IO的那部分开销分立开来么?我怀疑大部分时间花在IO上了 你blog中那个一次读入和分次读入的性能差别,也正好是I/O方式不同带来的,所以我觉得最好独立的测试IO的效率和分组的效率,那样比较才科学一些 |
|
返回顶楼 | |
发表时间:2006-09-18
buaawhl 写道 有一个题外的问题。 http://www.iteye.com/post/138935 这个link走到了页面的中间,定位到这个帖子的书签上。这个是如何做到的? 我只知道需要一个anchor http://www.iteye.com/post/138935#138935 难道有另外的通知browser哪里有书签的的HTML Meta or Element ? <script> if($('138935')) $('138935').scrollIntoView(true); new Effect.Highlight('138935_body'); </script> |
|
返回顶楼 | |
发表时间:2006-09-18
psyco目前只能支持32位x86平台,但是python正在向64位进军(python2.5的一个努力使得c/c++模块都需要重新调整和编译)
不知道YARV的硬件平台支持度如何 |
|
返回顶楼 | |
发表时间:2006-09-18
Ruby现在的Interpreter执行效率之低下那是不争之事实,GC算法那也是很简陋的,而且更加没有针对server做过GC优化(以至于有人给ruby打GC Patch)。YARV也刚刚起步,要对YARV做出评价,也为时尚早。其实我觉得这个评测没有什么值得去做的,因为结论早就明摆着的呢。
但是硬件的进步确实在抹平语言本身的执行低效率。JavaEye2.0的代码在本地笔记本上面运行已经非常缓慢了,但是部署在两路AMD64 CPU的服务器上面,却是跑的飞快,绝大多数带有七八条SQL查询(5万数据量)的Action其执行时间只有0.0X秒。而这台服务器也不过才12k而已。 |
|
返回顶楼 | |
发表时间:2006-09-18
levinfox 写道 有一个问题.
能够把IO的那部分开销分立开来么?我怀疑大部分时间花在IO上了 你blog中那个一次读入和分次读入的性能差别,也正好是I/O方式不同带来的,所以我觉得最好独立的测试IO的效率和分组的效率,那样比较才科学一些 可以用prof。但不要用ruby自带的,慢得要S。用ruby-prof这个gem比较好。 我测试过,Ruby的IO性能也不好。 |
|
返回顶楼 | |
发表时间:2006-09-18
robbin 写道 Ruby现在的Interpreter执行效率之低下那是不争之事实,GC算法那也是很简陋的,而且更加没有针对server做过GC优化(以至于有人给ruby打GC Patch)。YARV也刚刚起步,要对YARV做出评价,也为时尚早。其实我觉得这个评测没有什么值得去做的,因为结论早就明摆着的呢。
但是硬件的进步确实在抹平语言本身的执行低效率。JavaEye2.0的代码在本地笔记本上面运行已经非常缓慢了,但是部署在两路AMD64 CPU的服务器上面,却是跑的飞快,绝大多数带有七八条SQL查询(5万数据量)的Action其执行时间只有0.0X秒。而这台服务器也不过才12k而已。 在带数据库后端的Web站点上,脚本的执行效率确实不是至关重要。速度与多方面相关,服务器的配套、网络带宽等等,有瓶颈的话一般都在DB那端。 我作这个测试也只是出于好奇,让大家了解一下Ruby和Python的性能差距及YARV的效果。 ps.我还是觉得Javaeye 2.0有时反应挺迟钝的。而不像你所说的“飞快” |
|
返回顶楼 | |
发表时间:2006-09-18
引用 ps.我还是觉得Javaeye 2.0有时反应挺迟钝的。而不像你所说的“飞快” 我说的是ruby脚本执行速度飞快,这个是从rails的production.log里面统计出来的。 至于通过浏览器访问缓慢,原因可能比较复杂了。因为我自己还没有碰到缓慢的症状,查看production.log中Action也找不到一个执行时间超过1秒的,MySQL slow log也是空空的。所以我只能说不是程序执行慢。 |
|
返回顶楼 | |
发表时间:2006-09-18
robbin 写道 引用 ps.我还是觉得Javaeye 2.0有时反应挺迟钝的。而不像你所说的“飞快”
我说的是ruby脚本执行速度飞快,这个是从rails的production.log里面统计出来的。 至于通过浏览器访问缓慢,原因可能比较复杂了。因为我自己还没有碰到缓慢的症状,查看production.log中Action也找不到一个执行时间超过1秒的,MySQL slow log也是空空的。所以我只能说不是程序执行慢。 Ruby再怎么慢应付一般的Web开发肯定够用了撒(不然Rails也火不起来吧),因为繁重的活都交给了别人--静态页面渲染由Apache处理,查询由DB负责,还有Caching助阵。只是作为自己钟爱的一门语言,总会希望她的应用面能广些,而不只局限于Web这块。 |
|
返回顶楼 | |