這不是不看不知道，一看嚇一跳嘛，這不，我開始重新系統(tǒng)性的學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu)了，又回到我的老本行Python里去了，好家伙，Python 3更新的速度是真尼瑪?shù)目彀?，我前腳剛學(xué)完__peg_parser__，后面又來了個(gè)本不屬于Python語言的case語句，那我們就來簡單分析一下這兩個(gè)之間的運(yùn)行時(shí)間上的差異吧！

首先，基本代碼：

import time? # 導(dǎo)入時(shí)間庫

?

count_ifs = []? # 計(jì)算每次運(yùn)行if的時(shí)間

count_matchs = []? # 計(jì)算每次運(yùn)行match的時(shí)間

a = 10? # 這個(gè)數(shù)還會改改

times = eval(input("Please input times: "))? # 輸入程序運(yùn)行次數(shù)

for i in range(times):

??? begin_time = time.perf_counter_ns()? # 開始計(jì)時(shí)

??? match a:

??????? case 1:

??????????? pass

??????? case 2:

??????????? pass

??????? ......? # 此處省略若干行代碼

??????? case 9:

??????????? pass

??????? case _:

??????????? pass

??? end_time = time.perf_counter_ns()? # 終止計(jì)時(shí)

??? count_matchs.append(end_time - begin_time)? # 將時(shí)間差存放至count_matches列表

??? begin_time = time.perf_counter_ns()

??? if a == 1:

??????? pass

??? elif a == 2:

??????? pass

??? ......? # 此處省略若干行代碼

??? elif a == 9:

??????? pass

??? else:

??????? pass

??? end_time = time.perf_counter_ns()

??? count_ifs.append(end_time - begin_time)

print("if: %d" % round(sum(count_ifs) / times))? # 輸出if語句塊的平均運(yùn)行時(shí)間

print("match: %d" % round(sum(count_matchs) / times))? # 輸出match語句塊的平均運(yùn)行時(shí)間

?

這個(gè)操作有效的避免了其它的語句（pass語句除外）帶來的時(shí)間上的運(yùn)行差異。我們只需要考慮if語句和match語句即可，該程序的缺點(diǎn)就是隨著n的增大，代碼量也隨之上漲，所以這個(gè)程序，我們測到1000為止。

當(dāng)a取如下整數(shù)時(shí)：

當(dāng)a = 1時(shí)，運(yùn)行時(shí)間存在小于0.1 ns的誤差，忽略不計(jì)。其差異不是很明顯。此刻我們分析的是單分支語句

當(dāng)a = 2時(shí)，運(yùn)行時(shí)間存在超過1 ns的誤差，可以暫時(shí)認(rèn)為差異不是很明顯。此刻我們分析的是雙分支語句

當(dāng)a = 3時(shí)，運(yùn)行時(shí)間存在超過7 ns的誤差，可以暫時(shí)認(rèn)為差異不是很明顯。此刻我們分析的是最簡單的多分支語句

當(dāng)a = 10時(shí)，運(yùn)行時(shí)間的誤差約為64 ns，這個(gè)差值也不算很龐大。

當(dāng)a = 100時(shí)，運(yùn)行時(shí)間的誤差約為778 ns，這個(gè)差值其實(shí)也還好，連1 μs都沒到。

當(dāng)a = 1000時(shí)，運(yùn)行時(shí)間的誤差約為6413 ns，這個(gè)誤差看上去就稍微有點(diǎn)大了，大約為6 μs。

可以發(fā)現(xiàn)if語句運(yùn)算方面可能要比match case慢。

超過1000的我們就盡可能用循環(huán)吧，畢竟if雖然快，但這樣做代碼太長了。