這是c++性能測驗工具教程的第四篇文章，從本篇開始我將逐步介紹一些性能測驗的高級技巧，
前三篇教程可以看這里：
- c++性能測驗工具：google benchmark入門（一）
- c++性能測驗工具：google benchmark入門（二）
- c++性能測驗工具：計算演算法的時間復雜度
本文將會介紹如何使用模板以及引數生成器來批量生成測驗用例，簡化繁瑣的性能測驗代碼，
測驗物件
這次測驗的物件是標準庫的vector，我們將會在vs2019 16.10和Linux + GCC 11.1上進行測驗，為了代碼寫著方便，我還會啟用c++17支持，
這次的疑問來自于《A Tour of C++》這本書，最近在重新翻閱本書的時候發現書里第九章給出了一個很有意思的建議：盡量少用reserve方法，
我們都知道reserve會提前分配足夠大的記憶體來容納元素，這樣在push_back時可以減少記憶體分配和元素移動的次數，從而提高性能，所以習慣上如果我們知道vector中存盤元素的大致數量，就會使用reserve提前進行記憶體分配，這是典型的“空間換時間”，
而書中給出的理由僅僅是說vector的記憶體分配器性能已經很高，預分配往往是多此一舉，收效甚微，事實到底如何呢，性能問題光靠腦補是不能定位的，所以我們用實驗結果說話，
使用模板函式生成測驗
測驗用例的設計很簡單，我們定義普通vector和reserve過的vector，然后分別對其添加一定數量的元素（逐步從少到多）測驗性能，
同時vector本身是泛型容器，所以為了測驗的全面性我們需要測驗兩至三種型別引數，
如果針對每一種情況寫測驗函式，顯然違反了DRY原則，因為除了vector的型別引數不同，其他代碼幾乎是完全一樣的，
對于上面的需求，就需要模板測驗函式登場了：
template <typename T, std::size_t length, bool is_reserve = true>
void bench_vector_reserve(benchmark::State& state)
{
for (auto _ : state) {
std::vector<T> container;
if constexpr (is_reserve) {
container.reserve(length);
}
for (std::size_t i = 0; i < length; ++i) {
container.push_back(T{});
}
}
}
非常的簡單，我們通過length控制插入的元素個數；is_reserve則負責控制是否預分配記憶體，通過if constexpr可以生成reserve和不進行任何操作的兩種代碼（如果不熟悉c++17的if constexpr，推薦花兩分鐘看看這里），
然后我們像往常一樣定義一個測驗用例：
BENCHMARK(bench_vector_reserve<std::string,100>);
可是等我們編譯的時候卻報錯了！
$ g++ test.cpp -lpthread -lbenchmark -lbenchmark_main
test.cpp:19:48: 錯誤：宏“BENCHMARK”傳遞了 2 個引數，但只需要 1 個
19 | BENCHMARK(bench_vector_reserve<std::string,100>);
| ^
In file included from a.cpp:1:
/usr/local/include/benchmark/benchmark.h:1146: 附注：macro "BENCHMARK" defined here
1146 | #define BENCHMARK(n) \
|
test.cpp:19:1: 錯誤：‘BENCHMARK’不是一個型別名
19 | BENCHMARK(bench_vector_reserve<std::string,100>);
原因是這樣的，在編譯器處理宏的時候實際上不會考慮c++語法，所以分割模板引數的逗號被識別成了分割宏引數的逗號，因此在宏處理器的眼里我們像是傳了兩個引數，這也說明了BENCHMARK是處理不了模板的，
不過別擔心，Google早就想到這種情況了，所以提供了BENCHMARK_TEMPLATE宏，我們只需要把模板名字和需要的型別引數依次傳給宏即可：
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 1000);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 10000);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100000);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100, false);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 1000, false);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 10000, false);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100000, false);
現在就可以正常編譯運行了：
可以看到reserve過的容器性能幾乎比默認的快了一倍，
不過在揭曉為什么書上不推薦reserve的謎底之前，我們的代碼還有可以簡化的地方，
定制測驗引數
首當其沖的問題其實還是違反了DRY原則——除了數字，其他內容都是重復的，
看到這種代碼直覺就告訴我該做些改進了，
首先我們來復習一下Ranges，在《c++性能測驗工具：google benchmark入門（二）》中我們已經學習過它了，Ranges接受start和end兩個int64_t型別的引數，默認從start起每次累乘8，一直達到end，
通過RangeMultiplier我們可以改變乘數，比如從8改成10，
在這里我們的length引數其實是不必要的，所以代碼可以這樣改：
template <typename T, bool is_reserve = true>
void bench_vector_reserve(benchmark::State& state)
{
for (auto _ : state) {
std::vector<T> container;
if constexpr (is_reserve) {
// 通過range方法獲取傳入的引數
container.reserve(state.range(0));
}
for (std::size_t i = 0; i < state.range(0); ++i) {
container.push_back(T{});
}
}
}
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->RangeMultiplier(10)->Range(10, 10000 * 10);
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, false)->RangeMultiplier(10)->Range(10, 10000 * 10);
現在我們測驗的元素數量是[10, 100, 1000, 10^4, 10^5]，
除此之外還有另一種叫“密集引數”的Ranges，google benchmark提供了DenseRange方法，
這個方法的原型如下：
DenseRange(int64_t start, int64_t end, int64_t step);
Ranges是累乘，而DenseRange是累加，因為累乘會導致幾何級數的增長，在數軸上的分布越來越稀疏，累加則看上去像是均勻分布的，因此累加的引數生成器被叫做密集引數生成器，
如果我們把測驗用例這么改：
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->DenseRange(1000, 100 * 100, 1000);
現在我們的length就是這樣一個序列：[1000，2000，3000， ...，9000，10000]，
關于自定義引數最后一個知識點是ArgsProduct，看名字就知道這是一個引數工廠，
ArgsProduct(const std::vector< std::vector<int64_t> >& arglists);
std::vector<int64_t>實際上就是一組引數，arglists就是多組引數的合集，他們之間會被求笛卡爾積，舉個例子：
BENCHMARK(BM_test)->ArgsProduct({ {"a", "b", "c", "d"}, {1, 2, 3, 4} });
// 等價于下面的
BENCHMARK(BM_test)->Args({"a", 1})
->Args({"a", 2})
->Args({"a", 3})
->Args({"a", 4})
->Args({"b", 1})
->Args({"b", 2})
->Args({"b", 3})
...
->Args({"d", 3})
->Args({"d", 4})
我們可以看到引數工廠其實得自己手寫所有引數，那如果我想配合工廠使用Ranges呢？
沒問題，benchmark的開發者們早就想到了，所以提供了下面這些幫助函式：
benchmark::CreateRange(8, 128, /*multi=*/2) // 生成：[8, 16, 32, 64, 128]
benchmark::CreateDenseRange(1, 6, /*step=*/1) // 生成：[1, 2, 3, 4, 5, 6]
如果換成我們的例子，就可以這樣寫：
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, false)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
借助僅僅兩行代碼我們就能生成數量可觀的測驗用例：
當然，這只是一個型別引數，實際上我們還有另外兩個型別需要測驗，另外這是1.5.5新增的功能，如果你想嘗鮮得先升級google benchmark，
進一步簡化
通常做到上面那一步就足夠了，然而在這里我們還有優化空間，因為如果我們把其他兩個測驗用的型別加上，代碼是這樣的，MyClass的定義后面會給出：
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, false)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
BENCHMARK_TEMPLATE(bench_vector_reserve, std::size_t)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
BENCHMARK_TEMPLATE(bench_vector_reserve, std::size_t, false)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
BENCHMARK_TEMPLATE(bench_vector_reserve, MyClass)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
BENCHMARK_TEMPLATE(bench_vector_reserve, MyClass, false)->ArgsProduct({
benchmark::CreateRange(10, 10000*10, 10)
});
你看見了什么？沒錯，重復重復重復！我們又違背了DRY原則，
重復說不上什么十惡不赦，但能避免還是要避免的，所以我準備用宏來簡化這些代碼：
#define generate_test(type) \
BENCHMARK_TEMPLATE(bench_vector_reserve, type)->ArgsProduct({benchmark::CreateRange(10, 100000, 10)}); \
BENCHMARK_TEMPLATE(bench_vector_reserve, type, false)->ArgsProduct({benchmark::CreateRange(10, 100000, 10)});
generate_test(std::string);
generate_test(std::size_t);
generate_test(MyClass);
這下舒服多了，
接著來看我們的MyClass，我們的MyClass包含幾個虛函式，禁止移動賦值，同時被刻意設計成了非平凡復制，這樣的型別可以說是繞過了標準庫容器設計的大部分優化措施，算是個妥妥的反面教材，希望你的專案里盡量不要出現這種東西：
class MyClass {
public:
long i = 2L;
MyClass() { i = 2L; }
virtual ~MyClass() {}
virtual long get() { return i; }
MyClass& operator=(MyClass&&) = delete;
MyClass(const MyClass& obj) {
i = obj.i;
}
MyClass& operator=(const MyClass& obj) {
i = obj.i;
}
};
這個類其實就是針對記憶體分配器實作的，vector在重新進行記憶體分配后很可能靠移動語意或者memmove來移動資料，這兩者將導致重新分配記憶體導致的性能損失變小，不利于我們觀察vector的行為，所以我定制了這個類，
這是Windows上的結果，Linux上也差不多，到目前為止我們看到reserve過的vector有著驚人的性能，那書里說的到底是怎么回事呢？
揭曉答案
實際上上面測驗的都是我們明確知道vector一定會被插入N個元素不多不少的情況，
然而這種情況其實在開發中是不多見的，更多的時候我們只能得到vector里元素數量的平均數、眾數，甚至是一個沒什么可靠依據的經驗值，
所以試想一下這種情況，reserve給的引數是1000，而我的vector總是會插入1001~1005個引數，顯然1000是不夠的，除了reserve外還會進行一次記憶體分配，而且這次分配后很可能還需要把原先的元素都轉移過去（realloc不是總能找到合適的位置擴展已有記憶體，而且像MyClass那樣的類在c++17中是不能bitwise復制的），那么這樣的開銷究竟如何呢？我們還是拿測驗說話，
篇幅有限，所以我只能簡單模擬一下上述情況：
template <typename T, bool is_reserve = true>
void bench_vector_reserve(benchmark::State& state)
{
for (auto _ : state) {
std::vector<T> container;
if constexpr (is_reserve) {
container.reserve(state.range(0));
}
// 每次多插入兩個元素，這樣多半會導致一次記憶體分配（當然不保證一定會）
for (std::size_t i = 0; i < state.range(0)+2; ++i) {
container.push_back(T{});
}
}
}
編譯均使用Release模式和默認的優化級別，這是Linux上的測驗結果：
和我們預期的一樣，多出來的一次記憶體分配使reserve帶來的性能優勢蕩然無存，
有意思的是Windows上的結果：
奇怪的事情發生了，雖說多出的一次分配縮小了性能差距，但reserve任然帶來了明顯的優勢，
這里我就不賣關子了，我們直接看vector的原始碼，
首先是GCC11.1的，代碼在/usr/include/c++/11.1.0/bits目錄下，分散在vector.tcc和stl_vector.h中，其中push_back在容器記憶體不夠的時候會用_M_realloc_insert重新分配足夠的記憶體，這個函式在vector.tcc的432行有定義，使用_M_check_len計算重新分配的記憶體大小，
_M_check_len是關鍵，定義在stl_vector.h的1756行：
// Called by _M_fill_insert, _M_insert_aux etc.
size_type
_M_check_len(size_type __n, const char* __s) const
{
if (max_size() - size() < __n)
__throw_length_error(__N(__s));
const size_type __len = size() + (std::max)(size(), __n);
return (__len < size() || __len > max_size()) ? max_size() : __len;
}
__n在push_back的時候是1，所以不難看出GCC的vector的擴容策略是每次擴容一倍，
vs2019的stl實作開源在了github，關鍵代碼在這里，push_back在記憶體不夠的時候會呼叫_Emplace_reallocate，里面會呼叫_Calculate_growth計算重新分配的記憶體大小：
_CONSTEXPR20_CONTAINER size_type _Calculate_growth(const size_type _Newsize) const {
// given _Oldcapacity and _Newsize, calculate geometric growth
const size_type _Oldcapacity = capacity();
const auto _Max = max_size();
if (_Oldcapacity > _Max - _Oldcapacity / 2) {
return _Max; // geometric growth would overflow
}
const size_type _Geometric = _Oldcapacity + _Oldcapacity / 2; // 關鍵代碼
if (_Geometric < _Newsize) {
return _Newsize; // geometric growth would be insufficient
}
return _Geometric; // geometric growth is sufficient
}
_Newsize相當于前面GCC的__n，在push_back的時候是1，所以不難看出vs2019的vector增長策略是每次擴容0.5倍，
除此之外兩者的剩余部分大同小異，都是先分配新記憶體，然后在新記憶體里構建要插入的元素，再把其他元素移動到新記憶體里，就連移動元素的方式也差不多，都是先嘗試memmove，接著試試移動語意，最后讓復制操作兜底，
那么兩者肉眼可見的區別就只有擴容策略這一條了，所以這會帶來什么影響呢？看個例子：
#include <iostream>
#include <vector>
void test1(std::size_t len)
{
std::vector<int> v1, v2;
v2.reserve(len);
for (std::size_t i = 0; i < len; ++i) {
v1.push_back(1);
v2.push_back(1);
}
std::cout << "v1: " << v1.capacity() << '\n';
std::cout << "v2: " << v2.capacity() << '\n';
}
void test2(std::size_t len)
{
std::vector<int> v1, v2;
v2.reserve(len);
for (std::size_t i = 0; i < len + 1; ++i) {
v1.push_back(1);
v2.push_back(1);
}
std::cout << "v1: " << v1.capacity() << '\n';
std::cout << "v2: " << v2.capacity() << '\n';
}
int main()
{
test1(100000);
test2(100000);
}
/*
vs2019的運行結果:
v1: 138255
v2: 100000
v1: 138255
v2: 150000
GCC11.1.0的結果:
v1: 131072
v2: 100000
v1: 131072
v2: 200000
*/
如果是一個有10萬個元素的vector想要擴容，GCC就會比vs多分配50000個元素需要的記憶體，分配如此多的記憶體需要花費更多的時間，即使reserve帶來了性能優勢在這一步也都揮霍的差不多了，
激進的擴容策略讓GCC出現了明顯的性能波動，不過這只是出現上面那樣測驗結果的原因之一，兩個標準庫的allocator實作上的區別也可能是其中一個原因，不過msvc的分配器實作并不公開，所以最終是什么導致了上述的結果并不能輕易斷言，
總結
我們學習了如何使用模板和引數生成器創建大量測驗用例，以提高撰寫測驗的效率，
我們還順便了解了vector.reserve對性能的影響，總結規律有幾條：
- 如果明確知道vector要存放元素的具體數量，推薦reserve，性能提升是有目共睹的；
- 否則你不應該使用reserve，一來有提前優化之嫌，二是在使用libstdc++的程式上會產生較大的性能波動；
- 接上一條，reserve使用不當還會造成記憶體的浪費，
看來《A Tour of C++》的作者只說對了一半，這也證明了性能問題不能靠臆斷，一定要靠測驗來定位、解決，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288412.html
標籤：C++
上一篇：超級瀏覽器-爬蟲