从实际工作需要与经历说说我选择PYTHON的原因(附相关源代码)

    从实际工作经历中说说我选择python的原因

    这两天看到有人问为什么好多大公司为什么选择PYTHON,大公司有大公司的考虑,这里只是说说我从实际工作中碰到问题解决后的选择.
   
    呵,呵,我是蛮羡慕RUBY有个很流行的WEB开发框架,也挺有兴趣学习,WEB敏捷开发之道的一二版和programing ruby第2版也买了,可惜因为在的公司进行的都是企业开发,基本上都用JAVA,不能实际应用RAILS,那就当个人兴趣爱好学习了.

    去年有次我负责的一个项目需要处理几个文本文件出话单和联通对帐,每个话单文件的处理条数大概是150到200万条,那时候对ruby也有些了解了,脚本语言上手还是挺快的,就用RUBY写了个小程序,花了天把完成任务,记不清当时为什么又用PYTHON来写了个程序来比较,可能是因为这两个脚本语言都比较有名,想多了解比较下的原因吧.

    这个程序牵涉到的就是字符串比较和文件读写.(惭愧惭愧,处理时间有差距,但没有我以前说的那么巨大,因为我写的RUBY代码不够高效,有同学改进后的代码提升到3倍以内,详见后帖)
  
    跑程序的机子是台IBM的X60,使用的CPU是T5600,1.8G的,内存是2G,硬盘100G,操作系统是 XP+sp3 , ruby 是一键安装的 1.8.6 吧(今天装的是 1.8.6-27) , python 当时是 2.5.2 今天我用的是(2.6.2),因为准备写这篇帖子,原来的话单文件又比较大,上百M和牵涉到手机号码,就写了个python程序,来生成测试用的话单.

    我当时是先写了RUBY,然后按RUBY的写法,又再写了个PYTHON,代码几乎都是一模一样的,也没有考虑什么优化啊编程技巧啊这些,数据需要怎么处理,就用语言提供的数据类型和进行最基本的操作,反正只是个小程序,用了就完了,而且写个脚本程序都要搞很高深的编程技巧,优化技巧,这不就有些为难不是专业人士,就想用脚本程序解决下问题的人了吗?

    今天的测试结果:
    测试120万条记录,PYTHON跑了40多秒.
    200万记录的测试,python跑了55秒.

    我平时工作中会经常需要写小程序解决问题,经常牵涉到全省手机号码的处理,一处理就是几十上百万的记录条数,你要说RUBY慢到我不能忍受的地步,也不至于,不过毕竟都喜欢跑得快的程序不是,而且ruby最吸引我的WEB开发,因为工作关系,不能轻易用,平时还是写些小程序处理网络,处理文件用得多些.   

    所以我最后还是选择了PYTHON,web开发因为工作原因还是用JAVA.

    程序代码就贴在下面,压缩包里是所有的相关源文件
   
    执行 MakeTestData.py 指定数字 生成指定数字条数的话单,比如 MakeTestDagta.py 1200000 就生成120万条数据,里面的数据没有任何意义,就是为了达到测试量的数据而已,为了方便,发送和接收数据都设置为指定数据的一半.

    然后执行 RunPyTest.bat 或 RunRbTest.bat 进行相关的运行测试,运行完后报告运行时间.
   
    我是希望有人能指点为什么我写的ruby程序比python慢了挺多的,不说又会换回ruby,长长经验也是个好事情嘛...

    我刚才又测试了一下,100万条数据,环境如上,跑了10次,结果还是一样,100万条数据的测试结果python 27,要说明下大部分ruby的时间是花在了写结果文件上,看来是IO读写拖了后腿,内存之中的运行应该差不多?(有时间再比较下)不过我这个程序正好碰到了大量的文件读写,我的标题应该改下了,只是有一定的差距...

   去掉最后的文件写入,差异也是比较巨大的,PYTHON 10 秒, RUBY 80 秒..测试记录是100万条(去掉最后的文件写入后的代码比较简单,还是有这个差异,要继续寻找答案,呵...)

    好象也不算是拖后腿,ruby python 都是用了2/3的时间来写结果文件
   
    我注释掉rb中对format_data的调用,直接赋予'',rb后面的写文件就很快了,那就是字符串操作...?
   
   下面是python处理的代码:
    
     数据处理要求是这样的,分3大步:
     1.有一个等待发送状态报告文件来匹配数据的文件,里面包含得有
     移动发往联通
     wait-status.csv 中第一个字段为3
     和
     联通发往移动
     wait-status.csv 中第一个字段为4
     的所有记录
     首先读取等待状态报告文件中的数据到哈希表中去,根据第一个字段为3或者4取不同的字段作为key放入到2个不同的(发送和接收)哈希表中
    
     2.然后读取状态报告文件 status.csv 的每一行,根据第一个字段作为KEY尝试去取2个哈希表中的数据,
     取得到数据就根据是从哪个哈希表中取出的分别放到2个不同的数组(发送和接收)中去
      取不到就丢弃

     3.然后把这2个不同的数组中的每条数据转换组合后写到文件中(发送GMO,接收GMT)去就OK了
   

评论

47 楼 wosmvp 2009-05-04  

[code=ruby]
status_file   = File.open('status.csv')
wait_file     = File.open('wait-status.csv')
@status       = {}
gmo_result    = File.new('GMO','w')
gmt_result    = File.new('GMT','w')
send_num      = '00000000'
receive_num   = '00000000'

status_file.map do |x|
  a = x.split(',',2)
  @status[a[0]] = a[1][0,4]
end

wait_file.map do |x|
  time = (x[64,2] + x[67,2] + x[69,2] + x[72,2]+ x[75,2]).gsub(/\D/,'0')
  if x[0].chr == '3'
    gmo_result << "#{time}08515#{send_num.succ!}  00   #{x[22,11]}  #{x[34,11]}    0    #{@status[x[2,19]]}  0    #{x[56,3]}  085101  15    108511  13800851500     2008#{time}     2008#{time}  \n"
  else
    gmt_result << "#{time}08515#{receive_num.succ!}  00   #{x[22,11]}  #{x[34,11]}    0    #{@status[x[-12,10]]}  0    #{x[56,3]}  085101  \t    108511  13800851500     2008#{time}     2008#{time}  \n"
  end
end

gmo_result.close
gmt_result.close



先上个版本，您先比较比较速度？

46 楼 xuby 2009-05-04  

貌似Google现在资助了一个CPython改进项目，声称要把Python再提速5倍：
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

45 楼 xukong 2009-05-04  

呵,现在的话都说得...,我相信没有最快只有更快,但是你好歹起码给个软硬件环境,给个处理数据量啊这些再说噻...

我曾经用C++写过,但是因为时间紧,C++里面又没有现成的SPLIT(或者我不知道,C++我写得少),写了个初步的就没时间再整下去了,那个的可优化就更大了,我也就不拿出来现丑了...

44 楼 neora 2009-05-04  

没啥好比的,这段应用用ANSI C写速度能提高到8秒以内，你信不？

43 楼 welcomyou 2009-05-04  

搬个小板凳吧，这年头，不怕叫板，就怕较真。

42 楼 xukong 2009-05-04  

你只生成个2行的测试数据然后比较结果文件看下就知道了啊,90%的数据都是固定的...就是截取时间那繁琐了点

靠,都没注意到python的format_data中的split还调用了2次,写重了(To whosmvp:Like第84行: 我去掉了这行,程序可也没见有几倍的提升),不过RUBY可是没有写重的,呵

41 楼 wosmvp 2009-05-04  

楼上，我要要工作的唉……

------------

08100000085150000001 00           13980000001           13030000001 0 DELI 0 140 085101 15    108511 13800851500 20080810000000 20080810000000

以这行为例，他们的数据是从那里取的？
所有的数据只有三列，除第1个值不同，（它是怎样得来的？），还有电话号码顺序不同（GMO/GMT），其它完全相同？

也就是说我要写这个程序，只需要判断wait-status.csv里面的数据，如果第一个值为3,取出电话号码，加上上面的固定值保存到 GMO 文件中，如果第一个值为4,取出电话号码，加上上面的固定值保存保存到GMT中？

---------------
OK,第一个值是时间加增加值，第二个是半固定值，第三、四为电话号码，第五为固定值，第六为发送成功？ 第七为取出值 第八为固定值 第九为固定值 第十根据第二个来取 第十一为固定值 第十二与第十三相同为时间

40 楼 mikewang 2009-05-04  

wosmvp 写道

xukong 写道

没事,你只处理30万,50万的数据量也行的(再少就比较不出了,起码10万数据PYTHON都是0秒,RUBY是18秒左右,我也晕了,怎么10万数据差别还更大,原来我可还真没有比较只处理10万的量),也够常用的数量级了,结果就是保存格式化后,符合附件规范的文本文件啊

你起码要提供数据呀？

wosmvp 兄， 搞的怎么样了， 我看好你的50倍提升呀。不要让我们久等呀。

39 楼 xukong 2009-05-04  

seraphim871211 写道

wosmvp 写道

xukong 写道

呵,兄台,我真不知道你是怎么看帖子的,我页面上早就列出了3个脚本,压缩包里面也有对应的3个文件...

执行 MakeTestData.py 指定数字 生成指定数字条数的测试话单,比如 MakeTestDagta.py 1200000 就生成120万条数据,里面的数据没有任何意义,就是为了达到测试量的数据而已,为了方便,发送和接收数据都设置为指定数据的一半.

你准备在LINUX下测试?我看你回帖是在ARCH下跑的,听说RUBY在LINUX性能会好点?我个人习惯用UBUNTU,呵...

没钱人，用不起 Windows ……

PS:你不说我怎么知道……

看不懂之间的逻辑～

应该是回答我"你准备在LINUX下测试?"的,不错啊,在盗版横行的国内内忍受方便的盗版WIN的诱惑,只用LINUX,很好的了,我工作上的机子是正版的,家里的是蕃茄, 不过我也尽量买了正版软件的,嘿,嘿,原来买了KV200,买过一年的卡巴,买过QIM

38 楼 seraphim871211 2009-05-04  

wosmvp 写道

xukong 写道

呵,兄台,我真不知道你是怎么看帖子的,我页面上早就列出了3个脚本,压缩包里面也有对应的3个文件...

执行 MakeTestData.py 指定数字 生成指定数字条数的测试话单,比如 MakeTestDagta.py 1200000 就生成120万条数据,里面的数据没有任何意义,就是为了达到测试量的数据而已,为了方便,发送和接收数据都设置为指定数据的一半.

你准备在LINUX下测试?我看你回帖是在ARCH下跑的,听说RUBY在LINUX性能会好点?我个人习惯用UBUNTU,呵...

没钱人，用不起 Windows ……

PS:你不说我怎么知道……

看不懂之间的逻辑～

37 楼 xukong 2009-05-04  

wosmvp 写道

xukong 写道

呵,兄台,我真不知道你是怎么看帖子的,我页面上早就列出了3个脚本,压缩包里面也有对应的3个文件...

执行 MakeTestData.py 指定数字 生成指定数字条数的测试话单,比如 MakeTestDagta.py 1200000 就生成120万条数据,里面的数据没有任何意义,就是为了达到测试量的数据而已,为了方便,发送和接收数据都设置为指定数据的一半.

你准备在LINUX下测试?我看你回帖是在ARCH下跑的,听说RUBY在LINUX性能会好点?我个人习惯用UBUNTU,呵...

没钱人，用不起 Windows ……

PS:你不说我怎么知道……

呵,呵,我想说也说不了啊,所以我写了,但是你不知道怎么没看见我也没有办法啊...

36 楼 wosmvp 2009-05-04  

xukong 写道

呵,兄台,我真不知道你是怎么看帖子的,我页面上早就列出了3个脚本,压缩包里面也有对应的3个文件...

执行 MakeTestData.py 指定数字 生成指定数字条数的测试话单,比如 MakeTestDagta.py 1200000 就生成120万条数据,里面的数据没有任何意义,就是为了达到测试量的数据而已,为了方便,发送和接收数据都设置为指定数据的一半.

你准备在LINUX下测试?我看你回帖是在ARCH下跑的,听说RUBY在LINUX性能会好点?我个人习惯用UBUNTU,呵...

没钱人，用不起 Windows ……

PS:你不说我怎么知道……

35 楼 xukong 2009-05-04  

呵,兄台,我真不知道你是怎么看帖子的,我页面上早就列出了3个脚本,压缩包里面也有对应的3个文件...

也早就有了相关说明:
执行 MakeTestData.py 指定数字 生成指定数字条数的测试话单,比如 MakeTestDagta.py 1200000 就生成120万条数据,里面的数据没有任何意义,就是为了达到测试量的数据而已,为了方便,发送和接收数据都设置为指定数据的一半.

你准备在LINUX下测试?我看你回帖是在ARCH下跑的,听说RUBY在LINUX性能会好点?我个人习惯用UBUNTU,呵...

34 楼 wosmvp 2009-05-04  

xukong 写道

没事,你只处理30万,50万的数据量也行的(再少就比较不出了,起码10万数据PYTHON都是0秒,RUBY是18秒左右,我也晕了,怎么10万数据差别还更大,原来我可还真没有比较只处理10万的量),也够常用的数量级了,结果就是保存格式化后,符合附件规范的文本文件啊

你起码要提供数据呀？

33 楼 bluemare 2009-05-04  

翘首观望中，谁输谁赢，下注了

32 楼 xukong 2009-05-04  

没事,你只处理30万,50万的数据量也行的(再少就比较不出了,起码10万数据PYTHON都是0秒,RUBY是19秒左右,我也晕了,怎么10万数据差别还更大,原来我可还真没有比较只处理10万的量),也够常用的数量级了,结果就是保存格式化后,符合附件规范的文本文件啊

哦,SORRY,处理10万PYTHON是2秒左右,因为我在第3步处理前加了个运行时间提示,看晃了...

31 楼 wosmvp 2009-05-04  

引用

今天的测试结果:
    测试120万条记录,PYTHON跑了40多秒 RUBY跑了350多秒.
    200万记录的测试,可能量变引起质变吧,python跑了55秒,RUBY跑了855秒.

晕，当时看了这里…… 可能要我shutup了
OK，最后你需要的是什么结果？ 文件要保存什么数据？

30 楼 xukong 2009-05-04  

我的第一篇帖子就已经说得很清楚了:

数据处理要求是这样的,分3大步:
     1.有一个等待发送状态报告文件来匹配数据的文件,里面包含得有
     移动发往联通
     wait-status.csv 中第一个字段为3
     和
     联通发往移动
     wait-status.csv 中第一个字段为4
     的所有记录
     首先读取等待状态报告文件中的数据到哈希表中去,根据第一个字段为3或者4取不同的字段作为key放入到2个不同的(发送和接收)哈希表中
    
     2.然后读取状态报告文件 status.csv 的每一行,根据第一个字段作为KEY尝试去取2个哈希表中的数据,
     取得到数据就根据是从哪个哈希表中取出的分别放到2个不同的数组(发送和接收)中去
      取不到就丢弃

     3.然后把这2个不同的数组中的每条数据转换组合后写到文件中(发送GMO,接收GMT)去就OK了

其实有什么说明比代码更清楚呢,才百把行代码,最繁琐的就是format_data中转换格式的代码了,数据格式为附件中所述

呵,提高50倍,我原来的RUBY代码在我的X60上处理100万条数据是270秒(50万是125秒左右),提高50倍,那就是5.4(2.5)秒就处理完咯(不知道在你的机子上优化前跑了多少秒,除以50应该就是优化后的结果了),不错不错,看样子是碰到奥数成员了,我要好好学习下,闭嘴也认了,到时候就封帖...

29 楼 wosmvp 2009-05-04  

xukong 写道

呵,你的建议我当时就一一回复了,也不知道你看了回帖没有

本来懒的说了,不过刚放假回来,暂时还收不下心思来做事,就说几句咯:

1.也不知道你怎么改了几行代码,反正你的结论就建立在只处理了最多12行数据的基础上,就大声宣布已经比PYTHON的快了,然后对更大数据量的处理是你想,应该,决不会...呵...
2.然后你说的那几条建议,开口就说会几十倍的提升,不知道你做了测试没,反正我也没做测试,我也犯下经验主意错误,不过我仔细想了下,不觉得会有那么大的提升.
3.第84行的处理,我在前面已经说明过了(javaeye没有第几楼的标志,要不就引用了)
4.到最后,也没有讲说你是否进行了100万条数据,200万条数据的测试,结果是什么...

呵,反正随便开口说说总比做容易...

你还真烦唉……

写写你的代码逻辑关系，目的，我重新写一个Ruby版本，看看性能不能提升 50 倍以上行吗？ 如果可以，你闭嘴，如果不可以，我闭嘴！

（别让我看你代码的逻辑关系，我菜，看不懂！！！）

28 楼 ebeach 2009-05-04  

vlinux 写道

纯粹路过...做人要厚道，就事论事，如果认为标题过大可以友善的指出；如果认为可以优化自己又有时间，可以稍作优化建议，权当“有仇的报仇，没仇的炼拳头”。没必要贬低别人抬高自己的。

理应如此！