Hassan Syed
Hassan Syed

Reputation: 20496

Has anyone done a performance analysis of boost::asio?

I require socket-like local IPC. I used named pipes and overlapped IO on windows and I want to rewrite the application to boost::ASIO so that it can use UNIX domain sockets as well.

I've recently reviewed parts of the libevent library and I know it only supports socket() and select() for windows in the 1.4 version. As overlapped IO is very efficient leaving it out is obviously an unacceptable trait which is being adressed in version 2 (which is in alpha). Another example of sub-optimal implementation is the use of red-black trees vs. prio-queues for the timeout logic which was adressed somewhere along the line.

Does anyone have any opinions on the performance characteristics of boost vs libevent/libev. Does it have any glaring undesireable traits on certain platforms ? My aim for this question is that I do not want to pidgeon-hole the ASIO library unless I absolutely must. I want to know if boost::asio uses the most optimal OS primitives in the most optimal way.

Upvotes: 15

Views: 14408

Answers (3)

unixman83
unixman83

Reputation: 9963

In my opinion Boost.Asio is Windows-First, where most other free-software libraries are Linux-First. However the quality under Linux has always been good. Since this software got reveiwed by 20 people who did not participate in its development. Speed under Linux with multiple threads has been rapidly improved around the time the asker asked this question (2009): http://think-async.com/Asio/LinuxPerformanceImprovements

Speed under Windows has always been good. My biggest gripe is the design of UDP sockets, it is poorly implemented.

Upvotes: 3

Frunsi
Frunsi

Reputation: 7157

Also check this post about a locking problem in boost::asio, which may affect you.

Upvotes: 5

Sergey Miryanov
Sergey Miryanov

Reputation: 1830

I do performance tests of asio and my own impl on file reading (my blogpost entry) - in two words - asio shown good results.

Upvotes: 9

Related Questions