爲什麼boost :: circular_buffer在我的基準測試中這麼慢？

Question

讀rationale，提振:: circular_buffer看起來前途無量：

適宜實時和性能關鍵應用。

快速定時插入和刪除正面和背面的元素。

當我運行一個簡單的基準測試，模擬我的使用情況下，使用它作爲一個字節的緩衝區：

1. 寫一個更大的塊
2. 讀取小塊，直到空
3. 重複

的表現絕對糟糕，比我自己的hack和spsc_queue慢了不止4000x。

lin : 101 // 10240x 
lock: 109 // 10240x 
circ: 427 // 10x 

注意，對於circular的loopcount是10併爲他人loopcount是10*1024。參見工作示例here。

我是否完全錯誤地使用它，或者只是沒有設計基本的/ POD類型？

編輯：

採用與所提供的變化基準沒有完全解決上MSVC2015問題。還有100倍的因素。

lin : 69 // 10240x 
lock: 79 // 10240x 
circ: 9688 // 10240x 

一次如此緩慢插入幾個項目是有問題的。分配可以在這種特殊情況下工作，因爲在插入之前緩衝區已經耗盡，但這不是一個通用的解決方案。恢復spsc_queue在所有方面都勝出，它的速度很快，可以在不耗盡的情況下使用，並且可以在多線程環境中使用（在單個生產者單個用戶場景中）。

Answer 1

首先，確保基準是健全的。如果您不使用計算結果，編譯器會在您最不期待的時候將其作爲無效代碼來消除。

1. 您的圓形刪除看起來不理想。使用這個來代替：

   buffer.erase_begin(1024); // or indeed, use checked size see below 
   

   UPDATE

2. 這是損害性能的第二件事情 - 糟糕 - 是insert電話。在你的用例中，你可以使用assign，就像在競爭者中一樣，它被編譯成一個mempcy或者memmove。

3. 確保調試禁用是一個使用Nonius我的重構基準（定義NDEBUG和或BOOST_CB_DISABLE_DEBUG）

這裏：http://paste.ubuntu.com/15222217/

時鐘分辨率：平均值爲18.6412納秒（40960002次迭代）

benchmarking linear 
collecting 100 samples, 1 iterations each, in estimated 3.93727 s 
mean: 39.0804 ms, lb 39.0567 ms, ub 39.1051 ms, ci 0.95 
std dev: 124.19 μs, lb 111.153 μs, ub 141.079 μs, ci 0.95 
found 0 outliers among 100 samples (0%) 
variance is unaffected by outliers 

benchmarking lockfree 
collecting 100 samples, 1 iterations each, in estimated 4.78513 s 
mean: 37.0188 ms, lb 37.0106 ms, ub 37.0277 ms, ci 0.95 
std dev: 43.5788 μs, lb 37.3685 μs, ub 52.8458 μs, ci 0.95 
found 3 outliers among 100 samples (3%) 
variance is unaffected by outliers 

benchmarking circular 
collecting 100 samples, 1 iterations each, in estimated 9.78763 s 
mean: 62.884 ms, lb 62.8657 ms, ub 62.9041 ms, ci 0.95 
std dev: 98.0325 μs, lb 85.6543 μs, ub 119.395 μs, ci 0.95 
found 1 outliers among 100 samples (1%) 
variance is unaffected by outliers 

互動結果：http://stackoverflow-sehe.s3.amazonaws.com/57c2bfea-3e9d-4503-8d23-3b88209fc3ce/stats.html

沒有遊標：Live On Coliru

輸出

lin : 101 (checksum: -1741910392) 
lock: 89 (checksum: -1741910392) 
circ: 102 (checksum: -1741910392)