設置在深入到基準測試和性能分析之前，首先我們需要一個合適的環境。這意味著我們需要為這項任務配置我們的機器和操作系統。我的機器的規格如下：處理器：Intel(R)Xeon(R)CPUE5-2699v3@2.30GHz內存：32GB操作系統：Ubuntu16.04LTSKernel：4.4.0-75-generic我們的目標是得到可復現的結果，因此要確保我們的數據不會受到其它后臺進程、操作系統配置或任何其它硬件性能提升技術的影響。讓我們首先從配置用于性能分析的機器開始。
硬件功能首先，禁用所有硬件性能功能，也就是說要禁用IntelTurboBoost和HyperThreadingfromBIOS/UEFI。正如其官方網頁上說的那樣，TurboBoost是“一種在處理器內核運行，并可以在低于功耗、電流和溫度規格限制的情況下允許它們以高于額定頻率的速度運行的技術。”此外，HyperThreading是“一種可以更高效地利用處理器資源的技術，能使每個內核都能多線程運行。”這都是值得我們花錢購買的好東西。那為什么要在性能分析/基準測試中禁用它們呢？因為使用這些技術會讓我們無法得到可靠的和可復現的結果。這會讓運行過程發生變化。讓我們看個小例子primes.py，代碼故意寫得很糟糕。
這段代碼可在GitHub上查看：https://github.com/apatrascu/hunting-python-performance/blob/master/01.primes.py。你需要運行以下命令安裝一個依賴包：
pipinstallstatistics
讓我們在一個啟用了TurboBoost和HyperThreading的系統中運行它：
現在禁用該系統的睿頻加速（TurboBoost）和超線程（HyperThreading），然后再次運行這段代碼：
看看第一個案例的標準差為15%。這是一個很大的值！假設我們的優化只能帶來6%的加速，那我們怎么能將運行過程中的變化（runtorunvariation）和你的實現的差異區分開？相對而言，在第二個例子中，標準差減少到了大約0.6%，我們的新優化方案效果清晰可見。
CPU節能
禁用所有的CPU節能設置，并使用固定的CPU頻率。這可以通過在Linux功率調節器（powergovernor）中將intel_pstate改成acpi_cpufreq而實現。intel_pstate驅動使用英特爾內核（SandyBridge或更新）處理器的內部調節器實現了一個縮放驅動。acpi_cpufreq使用了ACPIProcessorPerformanceStates。下面讓我們先來檢查一下：
可以看到這里所使用的調節器被設置成了節能模式，而CPU的頻率范圍在1.20GHz到3.60GHz之間。這個設置對日常應用來說是很不錯的，但卻會影響到基準測試的結果。那么應該給調節器設置什么值呢？如果我們瀏覽一下文檔，我們可以看到我們可以使用以下設置：高性能（performance）：以最大頻率運行CPU節能（powersave）：以最小頻率運行CPU自定義（userspace）：按用戶指定的頻率運行CPU按需（ondemand）：根據當前負載動態調節頻率。可能跳至最高頻率，空閑時又會降低保守（conservative）：根據當前負載動態調節頻率。相比于按需模式，其頻率調節更加漸進我們要使用性能調節器（performancegovernor），并將頻率設置成CPU支持的最大頻率。如下所示：
現在你已經使用性能調節器將頻率設置成了固定的2.3GHz。這是最大的可設置的值，沒有睿頻加速（TurboBoost），它可以被用在XeonE5-2699v3上。要完成設置，請使用管理員權限運行以下命令：
如果你沒有cpupower，可使用以下命令安裝：
sudoapt-getinstalllinux-tools-commonlinux-header-`uname-r`-y
功率調節器對CPU的工作方式有很大的影響。該調節器的默認設置是自動調節頻率以減少功耗。我們不想要這樣的設置，所以從GRUB中禁用它。只需要編輯/boot/grub/grub.cfg（但是如果你在kernel升級上很小心，那么這將會消失）或在/etc/grub.d/40_custom中創建一個新的kernel入口。我們的boot行中必須包含這個flag：intel_pstate=disable，如下所示：
linux/boot/vmlinuz-4.4.0-78-generic.efi.signedroot=UUID=86097ec1-3fa4-4d00-97c7-3bf91787be83rointel_pstate=disablequietsplash$vt_handoff
ASLR（地址空間配置隨機發生器）
這個設置是有爭議的，參見VictorStinner的博客：https://haypo.github.io/journey-to-stable-benchmark-average.html。當我首次建議在基準測試時禁用ASLR時，那是為了進一步提升對那時在CPython中存在的ProfileGuidedOptimizations的支持。我為什么要說這個呢？因為在上面給出的特定硬件上，禁用ASLR可以將運行之間的標準差降低至0.4%。另一方面，根據在我的個人計算機（IntelCorei74710MQ）上的測試，禁用ASLR會導致Victor所提到的同樣的問題。在更小的CPU（比如IntelAtom）上的測試會帶來甚至更大的運行間標準差。因為這似乎并不是普遍適用的真理，而且很大程度上依賴于硬件/軟件配置，所以對于這個設置，我在啟用后測量一次，再禁用后測量一次，之后再進行比較。在我的機器上，我通過在/etc/sysctl.conf.中加入以下命令禁用了ASLR。使用sudosysctl-p進行應用。
kernel.randomize_va_space=0
如果你想在運行時禁用它：
sudobash-c'echo0>|/proc/sys/kernel/randomize_va_space'
如果你想重新啟用：
sudobash-c'echo2>|/proc/sys/kernel/randomize_va_space'
二、內存分析
我們為什么要關心這個問題？為什么我們不僅僅就關心性能？這些問題的答案相當復雜，但我會總結出來。PyPy是一個可選的Python解釋器，其相對于CPython有一些巨大的優勢：速度（通過其JustinTime編譯器）、兼容性（幾乎可以替代CPython）和并發性（使用stackless和greenlets）。PyPy的一個缺點是因為其JIT和垃圾一樣的回收站實現，它通常會使用比CPython更多的內存。但是在某些案例中，其的內存消耗會比CPython少。下面我們來看看你可以如何測量你的應用使用了多少內存。
診斷內存使用
memory_profiler是一個可用來測量解釋器運行一個負載時的內存用量的庫。你可以通過pip安裝它：
pipinstallmemory_profiler
這個工具的優點是它會在一個Python腳本中一行行地顯示內存消耗。這可以讓我們找到腳本中可以被我們重寫的位置。但這種分析有一個缺點。你的代碼的運行速度比一般腳本慢10到20倍。怎么使用它？你只需要在你需要測量的函數上直接加上@profile()即可。讓我們看看實際怎么操作！我們將使用之前用過的素材腳本作為模型，但做了一點修改，移除了統計部分。代碼也可在GitHub查看：https://github.com/apatrascu/hunting-python-performance/blob/master/02.primes-v1.py
開始測量時，使用以下PyPy命令：
pypy-mmemory_profiler02.primes-v3.py
或者直接在腳本中導入memory_profiler：
pypy-mmemory_profiler02.primes-v3.py
在執行完這行代碼之后，我們可以看到PyPy得到這樣的結果：
我們可以看到這個腳本使用了24.371094MiB的RAM。讓我們簡單分析一下。我們看到其中大多數都用在了數值數組的構建中。它排除了偶數數值，保留了所有其它數值。我們可以通過調用range函數而對其進行一點改進，其使用一個增量參數。在這個案例中，該腳本看起來像是這樣：
如果我們再次測量，我們可以得到以下結果：
很好，現在我們的內存消耗下降到了22.75MiB。使用列表解析（listcomprehension），我們還可以將消耗再降低一點。
再次測量：
我們最后的腳本僅消耗22.421875MiB。相比于第一個版本，差不多下降了10%。