歡迎關注生信寶典
長假結束了，這不痛苦。痛苦的是長假結束了，發現寫的基因組讀取程式還沒執行完？
在python系列教程中，我們提到乙個概念字串是不可修改的。這一點可以通過id函式來判斷確實是對的。但是這個概念會對我們寫作程式有什麼影響一直沒有特別深的理解。
直到有一次，實驗室乙個朋友要讀基因組資料，結果發現3 g的基因組讀一晚上都沒讀完，就很詫異，看了下**，這麼寫的。
基因組序列是grch38.fa，fasta格式，序列行每行70個字元，共44,284,892行 (記住行數有多大)，示例如下。
>chr1
nnnnn...(60個n)...nnnnn
acgta...(60個nt)...acgta
...>chr2
nnnnn...(60個n)...nnnnn
acgta...(60個nt)...acgta
...
adict = {}
for line in open("grch38.fa"):
if line[0] == '>':
key = line[1:-1]
adict[key] = ''
else:
adict[key]+=line.strip()
id，讀取一行附加在前一行後面，邏輯是對的。然後執行上程式，回去睡覺，滿心歡喜期待第二天早上出來獲得結果，結果啥也沒出來，程式還停留在讀取基因組序列步驟。
按我們伺服器的效能，這不應該啊。就看**是不是出問題了，怎麼看邏輯都對。後來就想會不會是序列累加的問題，就換了乙個寫法。**稍微長了些，先存入列表，再連線起來。
dict = {}
for line in open("grch38.fa"):
if line[0] == '>':
key = line[1:-1]
adict[key] =
else:
#--------------------------------
for key, value in adict.items():
adict[key] = ''.join(value)
time函式，檢視下執行速度，不足1分鐘。time及更多程式監測方法見命令執行監測和軟體安裝。
real
0m51.256s
user 0m40.729s
sys 0m10.425s
不比不知道，一比嚇一跳；速度差了何止幾千倍。
這時，我們重新理解下什麼叫字串不可修改。
使用id函式來確定字串累加跟列表累加的不同。(不同電腦或不同時間允許的id不同，不看具體數字，只看id的變化)
ehbio = "sheng xin bao dian"
id(ehbio)
## output: 140405359946640
ehbio += ' very good'
ehbio
## output: 'sheng xin bao dian very good'
id(ehbio)
## output: 140405344262576
id。就是說python在對變數ehbio新增字串時，是先開闢乙份記憶體空間，把ehbio原有內容加新內容組成的字串存入新的記憶體空間。而不是想象中的直接追加在已有字串的後面。這樣對4千萬行資料的操作就是要做4千萬次的記憶體空間開闢和字串儲存。這是乙個特別耗時的步驟。
而如果是乙個列表呢？
alist = ['sheng','xin']
id(alist)
## output: 140405344245520
id(alist)
## output: 140405344245520
alist.extend(["dian", "excellent"])
id(alist)
## output: 140405344245520
python使用中還有不少類似這樣的需要注意的小細節，在後續會陸續推出。
具體日期靜待公布。
為什麼我的並查集這麼慢！！！
在我剛開始使用並查集這種演算法的時候，我一直搞不明白為什麼別人總是說這種演算法很好，在做題的時候會經常用到。但是我自己用起來的時候時間總是會超，一直很納悶。今天重新做到一道別人都是使用並查集來解決的題目時，我才發現了我一直以來的錯誤！是真蠢呀！寫這篇部落格來吐槽一下自己，順便給自己留下乙個更深刻的印...
count 這麼慢，我該怎麼辦？
count 統計原理 innodb 是索引組織表，主鍵索引樹的葉子節點是資料，而普通索引樹的葉子節點是主鍵值。所以，普通索引樹比主鍵索引樹小很多。對於 count 這樣的操作，遍歷哪個索引樹得到的結果邏輯上都是一樣的。因此，mysql 優化器會找到最小的那棵樹來遍歷。在保證邏輯正確的前提下，儘量減少...
面試系列05 我的SQL為什麼這麼慢？
sql執行偶爾很慢 sql執行一直很慢 create index nameindex on tb user name 10 在tb user表以name欄位建立乙個名為nameindex的索引 explain select from tb user where name 鞠婧禕 通過關鍵字expla...