Python性能十分的強(qiáng)大，相關(guān)的技術(shù)為什么會如此的強(qiáng)大呢？下面我們就詳細(xì)的看看相關(guān)技術(shù)問題。問題的提出是源于 這位兄弟的BLOG，在他的這個實現(xiàn)中，Python性能具有相當(dāng)不錯的性能，不但優(yōu)于帖子中的C實現(xiàn)性能，也優(yōu)于隨后的跟貼中眾多的C++實現(xiàn)的性能。#t#

成都創(chuàng)新互聯(lián)10多年企業(yè)網(wǎng)站制作服務(wù);為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計及高端網(wǎng)站定制服務(wù),企業(yè)網(wǎng)站制作及推廣,對建筑動畫等多個方面擁有多年的網(wǎng)站推廣經(jīng)驗的網(wǎng)站建設(shè)公司。

在經(jīng)過了多次嘗試，我還是很難找出一個優(yōu)于Python性能的實現(xiàn)。這不是一件正常的事情，Python性能注定不會優(yōu)于C/C++，這是因為Python是解釋執(zhí)行的，解釋的過程必然會消耗CPU時間，所以我查閱了Python的源碼試圖找出為何Python性能對于這個任務(wù)有如此好的性能的原因。

任務(wù)描述如下

對于一個78W行的文本文件，每一行是一個Email地址，文件中存在有重復(fù)的行，任務(wù)的要求是盡可能快的從這個文本文件生成一個無重復(fù)的Email的文本文件

有如下的問題需要注意

對于這種大量的字符串比較，直接使用字符串比較函數(shù)是嚴(yán)重妨礙性能的IO性能是要注意的盡可能的少使用占用內(nèi)存在我的嘗試中，發(fā)現(xiàn)重復(fù)調(diào)用ofstream::operator<< 是比較影響性能的，而使用 fprintf或使用copy 等 STL 算法輸出到則性能好的多。使用一種好的Hash算法是影響程序性能的關(guān)鍵。任務(wù)中的EMail字符串總是具有[a-z]*[0-9]*@([a-z]*\.)+[a-z]* 的形式，例如 [email protected] [email protected] 的格式。

在$PySrc/Objects/dictobject.c 中，對Python的Hash機(jī)制作了一些描述，總的來說，Python的Hash機(jī)制對于這種連續(xù)型的字符串有相當(dāng)好的離散度，對于這個 78W 例子，python_hash() % 780000能夠很均勻的分散到各個值，***的沖突數(shù)為 8。 以下是按照類似 Python的 Hash算法實現(xiàn)的 C++ 版本的結(jié)果

 
 
 

  
  
  
E:\Workspace\Temp\Email>my   
  
  
  
經(jīng)過了1687.5000毫秒   
  
  
  
E:\Workspace\Temp\Email>my   
  
  
  
經(jīng)過了1718.7500毫秒   
  
  
  
E:\Workspace\Temp\Email>my   
  
  
  
經(jīng)過了1671.8750毫秒   
  
  
  
E:\Workspace\Temp\Email>my   
  
  
  
經(jīng)過了1656.2500毫秒   
  
  
  
E:\Workspace\Temp\Email>py_email.py   
  
  
  
2.82014641526   
  
  
  
E:\Workspace\Temp\Email>py_email.py   
  
  
  
2.74879181572   
  
  
  
E:\Workspace\Temp\Email>py_email.py   
  
  
  
2.76348586203   
  
  
  
E:\Workspace\Temp\Email>dir *.txt   
  
  
  
2006-03-28 13:09 19,388,869 email.txt   
  
  
  
2006-03-29 22:51 17,779,266 email_new.txt (py_email.py 寫出)   
  
  
  
2006-03-29 22:50 17,779,266 email_new_my.txt (my.exe 寫出)  
 
 
 

以上就是對Python性能的詳細(xì)介紹。

網(wǎng)頁題目：探究Python性能為什么如此的強(qiáng)大
標(biāo)題鏈接：http://uogjgqi.cn/article/dpipsjc.html