По следам обсуждения новости о библиотеке timertt на LOR-е. В обсуждении добрый человек предложил код теста, в котором запускается на обслуживание не много, ни мало, один миллиард таймеров (несколько раз нолики в числе пересчитывал, вроде девять):
|
#include <iostream> #include <cstdlib> #include "timertt/all.hpp" using namespace std; using namespace std::chrono; using namespace timertt; int main() { timer_wheel_thread_t tt; // Timer thread must be started before activation of timers. tt.start(); int counter = 0; for( int i = 0 ; i < 1000000000 ; ++i ) tt.activate( milliseconds( 100 ), [&counter](){ ++counter; } ); while( counter != 1000000000 ) this_thread::sleep_for( chrono::milliseconds( 100 ) ); cout << counter << endl; } |
С некоторым предательским чувством в коленках скомпилировал и запустил (MSVC++2013 64-bit, Win 8.1 64-bit):
bash-3.1$ time ./many_single_shot_timers.exe
1000000000
real 4m59.429s
user 0m0.000s
sys 0m0.015s
Таки миллиард таймеров за 5 минут, т.е. по 200 миллионов в минуту, т.е. по 3.3(3) миллиона в секунду. С учетом того, что профилированием и оптимизацией я не занимался, то получается вполне себе достойно. Честно скажу, вообще на таких объемах не запускал, не был уверен, что... :)))
Upd. Этот же тест, но с механизмом timer_list -- 4m31s, расход памяти приблизительно такой же -- около 42Mb. А вот timer_heap подкачал: 28m56s при расходе памяти под гигабайт. Вполне ожидаемый вывод: timer_heap не подходит для очень большого количества таймеров. Только удивительно, насколько именно не подходит.
PS. ЛОР -- торт! ;)