Hi Thorsten! --- Thorsten Ottosen <nesotto@cs.auc.dk> wrote:
I'm in doubt. The library has efficiency as its hallmark. The rationale says that it gives efficient FIFO queue. So I tried to compare it with std::deque, and here is my results of an /O2 build with vc71:
$ ./cbuffer_vs_deque.exe
circular_buffer<int>: 2.15 s
deque<int>: 2.84 s
circular_buffer<string>: 20.59 s
deque<string>: 18.64 s
I compiled your test and made some experiments with it. My results are: circular_buffer<int>: 2.84 s deque<int>: 3.84 s circular_buffer<string>: 27.65 s deque<string>: 25.65 s struct test_struct { double d; }; circular_buffer<test_struct>: 3.15 s deque<test_struct>: 4.22 s struct test_struct2 { double d1; double d2; double d3; double d4; double d5; }; circular_buffer<test_struct2>: 7.67 s deque<test_struct2>: 6.47 s It seems to me that if you use circular_buffer for storing "small" elements the circular_buffer is about 30% faster than deque. If you use larger elements the deque is faster about 10%. (I did also experiments with buffer size, but the results were about the same.) I don't have an explanation for such behavour. (Does anyone have?) So, the result is: the circular_buffer is more effective for storing primitive types. Btw, at the early stages of library developmet I implemented the circular_buffer as std::deque adaptor. The problem was that there was no control over iterator invalidation. Best regards, Jan __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com