經(jīng)過數(shù)十年的艱苦努力，Python才受到編程社區(qū)的贊賞。自2010年以來，Python蓬勃發(fā)展，并最終超過C，C#，Java和JavaScript。如今python可謂是我們?nèi)粘１容^常見的編程語言之一了。因此在使用Python進(jìn)行編程時(shí)遇到任何問題，只需在線搜索即可獲得答案。因?yàn)樵谀侵翱倳?huì)有人遇到這個(gè)問題，例如python中怎么排序數(shù)組，python為啥運(yùn)行效率不高等問題。

　　python中數(shù)組排序的方法：

1、一維數(shù)組采用sort函數(shù)進(jìn)行排序；

2、多維數(shù)組利用sort函數(shù)結(jié)合lambda匿名函數(shù)進(jìn)行排序。

　　1、數(shù)組排序

a = [3,1,4,6]

a.sort()

print(a)

執(zhí)行結(jié)果：

　　2、多維數(shù)組排

a = [['5.1.5.40580', 29], ['5.0.8.14000', 11], ['5.0.8.14999', 59], ['5.1.4.37882', 4]]

a.sort(key=lambda x:x[1],reverse=True)

print(a)

key=lambda x:x[1]：按照數(shù)組索引1列進(jìn)行排序，無此參數(shù)默認(rèn)以0列進(jìn)行排序。

reverse=True：倒序，無此參數(shù)默認(rèn)升序。

執(zhí)行結(jié)果：

　　python為啥運(yùn)行效率不高？

第一：python是動(dòng)態(tài)語言

一個(gè)變量所指向?qū)ο蟮念愋驮谶\(yùn)行時(shí)才確定，編譯器做不了任何預(yù)測(cè)，也就無從優(yōu)化。舉一個(gè)簡單的例子：　r = a + b?！和b相加，但a和b的類型在運(yùn)行時(shí)才知道，對(duì)于加法操作，不同的類型有不同的處理，所以每次運(yùn)行的時(shí)候都會(huì)去判斷a和b的類型，然后執(zhí)行對(duì)應(yīng)的操作。而在靜態(tài)語言如C++中，編譯的時(shí)候就確定了運(yùn)行時(shí)的代碼。

另外一個(gè)例子是屬性查找，關(guān)于具體的查找順序在《python屬性查找》中有詳細(xì)介紹。簡而言之，訪問對(duì)象的某個(gè)屬性是一個(gè)非常復(fù)雜的過程，而且通過同一個(gè)變量訪問到的python對(duì)象還都可能不一樣。而在C語言中，訪問屬性用對(duì)象的地址加上屬性的偏移就可以了。

第二：python是解釋執(zhí)行，但是不支持JIT（just in time compiler）。雖然大名鼎鼎的google曾經(jīng)嘗試Unladen Swallow 這個(gè)項(xiàng)目，但最終也折了。

第三：python中一切都是對(duì)象，每個(gè)對(duì)象都需要維護(hù)引用計(jì)數(shù)，增加了額外的工作。

第四：python GIL，GIL是Python最為詬病的一點(diǎn)，因?yàn)镚IL，python中的多線程并不能真正的并發(fā)。如果是在IO bound的業(yè)務(wù)場(chǎng)景，這個(gè)問題并不大，但是在CPU BOUND的場(chǎng)景，這就很致命了。所以筆者在工作中使用python多線程的情況并不多，一般都是使用多進(jìn)程（pre fork），或者在加上協(xié)程。即使在單線程，GIL也會(huì)帶來很大的性能影響，因?yàn)閜ython每執(zhí)行100個(gè)opcode（默認(rèn)，可以通過sys.setcheckinterval()設(shè)置）就會(huì)嘗試線程的切換，具體的源代碼在ceval.c::PyEval_EvalFrameEx。

第五：垃圾回收，這個(gè)可能是所有具有垃圾回收的編程語言的通病。python采用標(biāo)記和分代的垃圾回收策略，每次垃圾回收的時(shí)候都會(huì)中斷正在執(zhí)行的程序，造成所謂的頓卡。infoq上有一篇文章，提到禁用Python的GC機(jī)制后，Instagram性能提升了10%。感興趣的讀者可以去細(xì)讀。

以上就是關(guān)于python中怎么排序數(shù)組，以及python為啥運(yùn)行效率不高的全部內(nèi)容，想了解更多關(guān)于python的信息，請(qǐng)繼續(xù)關(guān)注中培偉業(yè)。