Кто-нибудь сделал анализ производительности boost:: asio?

Мне нужен локальный IPC сокета. Я использовал именованные каналы и перекрывал IO на окнах, и я хочу переписать приложение для boost:: ASIO, чтобы он мог также использовать сокеты домена UNIX.

Недавно я просмотрел части библиотеки libevent, и я знаю, что он поддерживает только socket() и select() для окон в версии 1.4. Поскольку перекрытие IO является очень эффективным, оставляя его, очевидно, является неприемлемым признаком, который адресуется в версии 2 (которая находится в альфа). Другим примером субоптимальной реализации является использование красно-черных деревьев против prio-queues для логики тайм-аута, которая была где-то вдоль линии.

Есть ли у кого-нибудь мнения о характеристиках производительности boost vs libevent/libev. Есть ли какие-либо вопиющие нежелательные черты на определенных платформах? Моя цель в этом вопросе заключается в том, что я не хочу, чтобы я не мог заглянуть в библиотеку ASIO, если я не буду абсолютно обязан. Я хочу знать, если boost:: asio использует наиболее оптимальные примитивы ОС наиболее оптимальным способом.

Ответ 2

Я выполняю тесты производительности asio и свой собственный имп для чтения файла (мой блогпост записи) - в двух словах - asio показал хорошие результаты.

Ответ 3

По-моему Boost.Asio есть Windows-First, где большинство других бесплатных программных библиотек Linux-First. Однако качество под Linux всегда было хорошим. Так как это программное обеспечение получили 20 человек, которые не участвовали в его разработке. Скорость под Linux с несколькими потоками была быстро улучшена примерно в то время, когда об этом задавал этот вопрос (2009): http://think-async.com/Asio/LinuxPerformanceImprovements

Скорость под Windows всегда была хорошей. Моя самая большая проблема - дизайн сокетов UDP, он плохо реализован.