輪詢與recv，epoll與recv和簡單recv之間的性能明智的區別？

Question

輪詢與recv，epoll與recv和簡單recv之間的性能明智差異是什麼？ 我有4個組播流，我必須聽我想我有三個選項。我希望在速度，系統調用，上下文切換等方面更好的是 。

1 poll with recv 
2 epoll with recv 
3 4 threads with recv 

請給我建議，這是更好，爲什麼

Answer 1

它將沒有多大關係，你選擇三個解決方案，差異不會很大。然而有一個可以讓你保存系統調用（見最後）。

對於4個描述符，可以假設poll幾乎與epoll一樣快。這對於400或4000個描述符來說會大不相同，但對於4個描述符，poll是絕對可以接受的（儘管您仍然可以使用epoll當然，只是不要期待奇蹟）。關於epoll的重要之處在於它如何在它所觀察的描述符數量方面進行擴展，而不是監視其中很少數量的速度有多快。

輪詢（使用任一功能）然後接收顯然比在一個線程中直接接收多一個系統調用，雖然取決於你的問題的性質，這可能是一個太天真的看待它。
如果來自這4個組播地址的數據報可以獨立處理，您可以在每個端口啓動一個進程，並在recv（最簡單的解決方案！）上阻止，但除此之外，您需要某種類型的同步，這很難實現如果你以前沒做過，哪些可能（將）涉及額外的系統調用或旋轉，並且很可能比多路複用接收慢。

無論您是否有線程，上下文切換的數量將大致跟隨系統調用的數量（因爲無論如何，您大部分時間都會在系統調用中阻塞），除非您的計算機非常繁忙且備用核心極少。在這種情況下，向遊戲中投擲線索將會大大增加上下文切換的次數。

多播假定UDP，意思是「完整的數據報」。既然你考慮使用epoll你已經決定可移植性不是問題。因此，您可以使用另一個特定於Linux的系統調用：recvmmsg。這允許您只接收一個系統調用的幾個數據報。如果你只有一個插座，那麼你就會阻止它，因爲它提供了一個「接收高達n」的功能。但是，由於您仍然需要複用4個插槽，因此首先使用epoll，然後使用recvmmsg。