想要讓程式跑得更快能有什麼方式呢?一個看似笑話卻也是作法之一的方式是「什麼事都不要做」,等著下一代處理器上市,然後,跑一下評測(Profiling)工具,接著就可以看到底改進了多少。

不過,就算是這個方式,開發者總也得知道什麼是評測工具,以及目前有哪些類型的評測工具可以使用。

在知道能有多快之前

坦白說,對於重視自我能力提升的開發者而言,接觸一門語言或技術越久,多半寫出的程式效能也不會太差,因為他對語言或技術中的基本元素越是如數家珍,越是清楚這些基本元素的特性,包括對效能的影響,因而在撰寫程式時,自然而然就會採用適當的元素,避免對效能產生不良的影響。

有的人會持反對意見,通常就拿出了「過早最佳化是萬惡根源」這面大旗,然而Donald Ervin Knuth實際上談到的是「97%的情況下,過早最佳化是萬惡根源。然而,我們不該放棄那關鍵的3%。」在網路上搜尋一下效能分析、效能調校之類的文章,或者尋找相關書籍,很容易就能發現,不少調整效能的方式,都是與語言或技術本身相關的基本元素。

談到效能,實際上無論任何程式,都受到三種限制,CPU的速度、記憶體,以及輸入輸出。語言或技術中的基本元素,對這三者可能會有著各自不同的影響,有時甚至只是版本上差異,也會有顯著的影響。

舉例來說,對Java開發者來說,HashMap是再基本不過的元素,然而,在HashMap的容量增長下,JDK8與JDK7的get()相比,時間複雜度分別是O(logn)與O(n),這是因為兩個版本的內部演算實作不同,在內部的桶(Bucket)容量過大時,JDK8的實作會有一個專用的紅黑樹結構來作為替代。

這類語言技術基本元素的特性,會不會影響程式的效能,當然也是得視程式的實際需求而定,也許開發者的應用程式實際執行時,並不會產生大容量的HashMap,這代表著對應用程式需求的瞭解,以及語言技術的使用經驗,能夠告訴開發者,在程式一開始的撰寫就該怎麼做,而又不至於落入萬惡的97%根源,若有能力進行關鍵的3%,也不影響程式的維護性,那就做吧!接下來,若能加上個評測工具,就有個堅強的後盾了。

簡單的計時工具

不同的評測工具有著不同的分析方式,最簡單的計時機制就是在程式中安插程式碼,量測目標程式執行的起始時間與結束時間,然後透過print之類的陳述,將執行前後的時間差顯示出來,這種方式通常用在計算密集式的程式片段或函式呼叫,以便粗略瞭解耗費的整體時間,像這類的方式基本上稱為Instrumentation,安插程式的方式,實際上,視評測工具而有所不同,有些高階的評測工具,則可以在執行時,將Instrumentation安插至被載入記憶體的可執行程式碼中。

若語言本身內建評測工具,都會提供簡單的模組來進行這類計時機制,像是Python的timeit,建議使用這類內建模組,或者是使用第三方程式庫,而不是自行撰寫。在《Dive Into Python》中,也提到「在最佳化Python程式碼時,最重要事是知道:不要自己撰寫計時函式。」

舉例來說,因為平臺本身的一些變數,每次的計時可能得到不同的結果,通常得重複執行相當次數,從中求得穩定的結果;另外,語言本身可能就有些技術上的變因,像是Python直譯器本身對方法的的查找是否作了快取,或者是垃圾回收機制是否停用之類的問題——一個事實是,timeit會停用垃圾收集機制,以避免垃圾回收的影響。如果語言內建計時機制,就算開發者曾經在其他地方看過簡單的介紹,使用前也應該詳閱它的文件,瞭解可以指定的參數,從中瞭解它做了什麼事,以及可能遇到的陷阱。

抓出最慢的傢伙

簡單的計時機制,可用來測試程式片段或者是某個函式呼叫,舉例來說,在Python中,若不確定函式的實作要使用tuple比較快,或者是list比較快,那麼就可以使用timeit做個測試;然而,有時必須在數個函式呼叫之間,找出效能瓶頸來加以改善,畢竟如果改某個地方,程式完成請求只能加快一秒,而改另一個地方,程式卻能加快十秒,那麼後者的改善,顯然效益要來得多。

以Python來說,這類的功能可以透過cProfile模組來達成,通常會搭配pstats來對取得的數據進行排序,通常會令我們感興趣的資料是累積時間(cumulative time, cumtime),這包括了花費在函式本身,以及所有子函式的時間,可以馬上知道哪個部份最為緩慢,也可以看看花在函式本身的總時間(total time, tottime),總時間不包含子函式呼叫,因此若函式本身的總時間花得不多,那麼大部份時間就可能花費在子函式。

函式本身可能被呼叫數次,因而造成cumtime或tottime的有較大的數字,如果在意的是單次呼叫的效能,可以看看cumtime與tottime的percall資料,這會是將cumtime與tottime分別除於呼叫次數(ncalls)的結果,根據這類的資訊,開發者可以決定減少呼叫次數,或者是改進函式本身的演算來試著增進效能。

評測工具本身畢竟本身也是個程式,執行時需要佔據一些系統資源,或者因為評測工具本身設計時技術上的問題,帶來了一些額外的負擔,有些評測工具可以進行校準(calibrate),以便在效能量測之後,能將相關的負擔捨去,例如Python的profiler模組,因為是使用純粹的Python撰寫,負擔上比cProfile來得大,為此profiler模組的Profiler實例,提供了calibrate()方法可用來獲得平臺上的校準常數,以便進一步將獲得的結果,設定為Profiler實例的bias值來作為校準時的捨去值。

空間與時間的交錯

相對於時間的問題,空間的問題比較少人在討論,畢竟現在記憶體越做越大,許多開發者很少在乎空間的問題,更多的情況下,還會有空間換時間的實作方式,像是使用各式的物件池、快取等就是個例子,將建立時需要昂貴運算的資源,設計成可重複使用,因此,通常會是實務效能調校時一個考量的方向。

不過,確實會有因空間而引發的效能問題,記憶體洩漏就是一個情況,此時必須有個空間的評測工具,像是Python中有memory_profiler,可以在原始碼一行一行的基礎上,量測記憶體的使用狀況(時間上的逐行方案則有line_profiler),有時必須要知道,哪種物件耗用了最多的記憶體,像是Python中可以使用heapy來獲得這類資訊。

空間問題與時間問題,基本上是一體的兩面,在現在程式語言多半具有垃圾回收機制的情況下,會讓問題更加複雜,因為,就算沒有記憶體洩漏之類的問題,隨著應用程式運行時間越長,記憶體中的物件越多,垃圾回收時耗費的時間也會成為效能問題之一。

在Java的領域很重視這類問題,有些評測工具可以觀察記憶體中不同世代(Generation)之狀況,亦有不同的演算法可供不同應用程式類型選擇。Python也是採分代回收,可透過gc模組來取得一些資訊,或者對不同世代做些控制。

效能評測工具基本上都不困難,也不應該因難,畢竟效能分析已經夠困難了,沒有理由使用一個困難的工具來做這件事,在試著效能調校之前,先找出能理解、易使用的評測工具是最重要的,如果太複雜,就別去使用它!

作者簡介


Advertisement

更多 iThome相關內容