Looking into understanding the performance of rosbag recorder, I stumble over something which seems to be a performance bottleneck. The actual usecase is to record about >300 topics with varying publication rate. The test setup used for performance measurement and profiling is a single rosbag recorder recording 309 active topics over a period of 2 minutes with no compression. The run is profiled using VTune and profiler data analyzed.

The performance of the existing topic monitoring is shown in the following graph:

Based on those findings, the top CPU usage of the rosbag recorder goes to the ros::PollSet class. This class is polling all file-descriptors which is known to be an inefficient strategy when monitoring over 100 sockets. The poll system call handles descriptors in a linear way. (source: https://daniel.haxx.se/docs/poll-vs-select.html)

In addition to my investigation, I've also implemented a event based implementation (using libev) as a comparison and also profiled the application which yield much better performance as seen in the graph:

So, I'd like to ask if anyone has already looked into asynchronous topic socket monitoring and if not, would a modification like the one proposed be of interest?