我們利用Percepio的Tracealyzer來深入了解同一算法的兩種不同實現(xiàn)的性能。具體來說，我們確定使用迭代函數(shù)而不是遞歸函數(shù)實現(xiàn)生成斐波那契數(shù)列的算法性能更高。我們不需要在序列中生成大量條目并測量時間來識別性能差異;相反，我們能夠使用 Tracealyzer 讓我們深入了解實現(xiàn)的性能，同時在序列中僅生成 10 個條目。

由于斐波那契序列生成器是在 Python 中實現(xiàn)的，讓我們進(jìn)一步擴(kuò)展一下。關(guān)于StackOverflow的一些主要問題與特定算法的最有效和“Pythonic”實現(xiàn)有關(guān)。在本文中，我們將研究一個流行的操作：反轉(zhuǎn)列表。

根據(jù)以下關(guān)于 StackOverflow 的問題，在反轉(zhuǎn)列表時，關(guān)于一個實現(xiàn)相對于另一個實現(xiàn)的性能存在一些爭論。為了深入了解差異，我們可以在一個簡單的應(yīng)用程序中實現(xiàn)這兩種技術(shù)，如下面的列表所示;我們還包括必要的源代碼，以捕獲 Tracealyzer 評估每個實現(xiàn)的性能所需的標(biāo)記：

import logging

def example（）：

list_basis = list（range（10））

logging.basicConfig（）

logger = logging.getLogger（‘my-logger’）

logger.info（‘Start’）

reverse_list = reversed（list_basis）

logger.info（‘Stop’）

logger.info（‘Start’）

reverse_list = list_basis［：：-1］

logger.info（‘Stop’）

if __name__ == ‘__main__’：

example（）

我們創(chuàng)建了一個包含 10 個元素的列表，并使用內(nèi)置的“反轉(zhuǎn)”函數(shù)以及 Python 中稱為“切片”的技術(shù)來反轉(zhuǎn)列表。切片只是獲取列表中的某些元素并將它們返回到新列表;在我們的例子中，我們正在切片整個列表，但向后遍歷。

與上一篇博客文章一樣，我們可以創(chuàng)建一個 LTTng 會話，運(yùn)行我們的 Python 腳本，在 Tracealyzer 中打開生成的跟蹤，并評估結(jié)果：

我們可以看到，使用反向函數(shù)的實現(xiàn)大約需要 475 微秒，使用切片的實現(xiàn)大約需要 360 微秒。

讓我們看看當(dāng)我們將初始列表中的元素數(shù)量增加 10 倍時會發(fā)生什么，從而得到一個由 100 個元素組成的列表：

import lttngust

import logging

def example（）：

list_basis = list（range（100））

logging.basicConfig（）

logger = logging.getLogger（‘my-logger’）

logger.info（‘Start’）

reverse_list = reversed（list_basis）

logger.info（‘Stop’）

logger.info（‘Start’）

reverse_list = list_basis［：：-1］

logger.info（‘Stop’）

if __name__ == ‘__main__’：

example（）

同樣，我們重新運(yùn)行必要的步驟來創(chuàng)建 LTTng 會話，運(yùn)行我們的應(yīng)用程序，并在 Tracealyzer 中打開生成的跟蹤，它向我們顯示了下圖：

雖然我們看到與以前相同的模式，其中切片技術(shù)比反向函數(shù)表現(xiàn)更好，但我們可以看到，與只有 10 個元素的結(jié)果相比，這兩種機(jī)制的絕對時間幾乎減少了一半。這很有趣，因為我們預(yù)計，與 100 個元素的情況相比，在 10 個元素的情況下，這兩種技術(shù)所花費(fèi)的時間應(yīng)該更少。讓我們通過首先更新 Python 腳本來收集更多數(shù)據(jù)，以允許我們以自動方式收集更多數(shù)據(jù)：

import lttngust

import logging

import sys

def example（list_size）：

list_basis = list（range（list_size））

logging.basicConfig（）

logger = logging.getLogger（“my-logger”）

logger.info（“Start”）

reverse_list = reversed（list_basis）

logger.info（“Stop”）

logger.info（“Start”）

reverse_list = list_basis［：：-1］

logger.info（“Stop”）

if __name__ == ‘__main__’：

example（int（sys.argv［-1］））

在上面的例子中，我們只是允許自己在列表中傳入我們想要的元素數(shù)量。然后我們可以創(chuàng)建以下 bash 腳本，這將允許我們執(zhí)行 Python 應(yīng)用程序，連續(xù)給它一個 10 和 100 的參數(shù)，收集使用反向函數(shù)和切片方法反轉(zhuǎn)列表所需的時間，并存儲該數(shù)據(jù);腳本將循環(huán)瀏覽每個測試 10 次。

#！/bin/bash

set -e

list_compare（） {

echo “Running test with a list size of $1 elements”

lttng create

lttng enable-event --kernel sched_switch

lttng enable-event --python my-logger

lttng start

python3 list_compare.py $1

lttng stop

lttng destroy

}

for i in {1..10}

do

list_compare 10

cp -r ~/lttng-traces/auto* “/home/pi/percepio/elements_10_trace_$i”

chown -R pi： “/home/pi/percepio/elements_10_trace_$i”

mv ~/lttng-traces/auto* ~/lttng-traces/archive/

list_compare 100

cp -r ~/lttng-traces/auto* “/home/pi/percepio/elements_100_trace_$i”

chown -R pi： “/home/pi/percepio/elements_100_trace_$i”

mv ~/lttng-traces/auto* ~/lttng-traces/archive/

done

當(dāng)我們在 Tracealyzer 中打開生成的跡線并繪制圖表時，我們會看到以下趨勢：

黃色和橙色圖表示 10 個元素列表的反轉(zhuǎn)時間，綠色和深紅色圖表示 100 個元素列表的反轉(zhuǎn)時間相同。我們可以看到一些實例，其中 10 個元素列表反轉(zhuǎn)的執(zhí)行時間與 100 個元素結(jié)果的執(zhí)行時間一致。類似地，我們可以看到，有一個實例減少了反轉(zhuǎn) 100 個元素列表的執(zhí)行時間，并且與反轉(zhuǎn) 10 個元素列表的執(zhí)行時間相同。但是，總的來說，我們可以看到反轉(zhuǎn) 10 個元素列表的執(zhí)行時間大約是反轉(zhuǎn) 100 個元素列表所需時間的一半。

也許我們在前一個案例中觀察到了這些異常之一？讓我們分析包含 1000 個元素的結(jié)果：

同樣，我們看到相同的模式，與使用反向功能相比，使用切片技術(shù)花費(fèi)的時間更少。但是，即使我們再次將列表中的元素數(shù)量增加了 10 倍（達(dá)到驚人的 1000 個元素），每個實現(xiàn)的時間與 100 個元素的時間大致相同，與只有 10 個元素相比，時間仍然是一半的時間。

讓我們將列表大小增加到 100k 個元素并觀察結(jié)果：

以前我們觀察到切片技術(shù)花費(fèi)的時間大約是反向函數(shù)的一半，而在這里我們可以看到相反的情況。事實上，對于 100k 個元素的列表大小，切片技術(shù)花費(fèi)的時間大約延長了 15 倍！

總之，我們從這個簡單的練習(xí)中獲得了一些寶貴的見解。首先，與反向函數(shù)相比，切片技術(shù)似乎花費(fèi)的時間更少，對于“幾個”元素的列表大小（最多 1000）。但是，當(dāng)我們將列表大小增加到 100k 個元素時，我們可以看到切片技術(shù)比反向函數(shù)花費(fèi)大約 15 倍的時間。其次，當(dāng)我們運(yùn)行較小大小列表的多次迭代時，我們確實注意到反轉(zhuǎn)包含 100 個元素的列表的時間與反轉(zhuǎn)包含 10 個元素的列表的時間大致相同的實例;然而，總體趨勢是，反轉(zhuǎn)包含 10 個元素的列表比反轉(zhuǎn)包含 100 個元素的列表花費(fèi)的時間更少，這是意料之中的！我們可以更詳細(xì)地分析Tracealyzer捕獲的痕跡，以了解觀察到的異常的原因。

這里的關(guān)鍵要點(diǎn)是，Percepio 的 Tracealyzer 使我們能夠在沒有太多儀器基礎(chǔ)設(shè)施的情況下執(zhí)行這種詳細(xì)的分析;我們能夠辨別出大約 100 微秒的性能數(shù)字！

由于Python一直是機(jī)器學(xué)習(xí)的流行語言，因此我們必須擁有一個工具，可以快速將一種算法的性能與另一種算法的性能進(jìn)行比較。我們可以開發(fā)一些小函數(shù)來隔離我們要評估的算法，并使用 Tracealyzer 為我們提供有關(guān)算法在不同維度的性能的必要見解。Tracealyzer還可以快速發(fā)現(xiàn)可能需要進(jìn)一步分析的異常行為。

審核編輯：郭婷