Neočekával bych, že mezi spuštěnou hranou a úrovní uvidím velký rozdíl ve výkonu.
Pro spouštění hranou musíte vždy vyprázdnit vstupní vyrovnávací paměť, takže máte jedno zbytečné (právě vrací EWOULDBLOCK) recv systémové volání. Ale pro spouštěnou úroveň můžete použít více systémových volání epoll_wait. Jak upozorňuje manuálová stránka, vyhnout se hladovění může být o něco snazší v režimu spouštění úrovní.
Skutečný rozdíl je v tom, že když chcete použít více vláken, budete muset použít režim spouštění okrajem (ačkoli stále budete muset být opatrní se správnou synchronizací).
Rozdíl je viditelný pouze tehdy, když používáte dlouhodobé relace a jste nuceni neustále zastavovat/spouštět kvůli plné/prázdné vyrovnávací paměti (typicky s proxy). Když to děláte, nejčastěji potřebujete mezipaměť událostí, a když vaše mezipaměť událostí zpracovává události, můžete použít ET a vyhnout se všemu tanci epoll_ctl(DEL)+epoll_ctl(ADD). U krátkodobých relací jsou úspory méně zřejmé, protože pro ET budete potřebovat alespoň jedno volání epoll_ctl(ADD) k aktivaci dotazování na FD, a pokud neočekáváte, že jich během trvání relace budete mít více (např.:burzy jsou většinou menší než buffery), pak byste neměli očekávat žádný rozdíl. Většina vašich úspor bude obecně pocházet pouze z použití mezipaměti událostí, protože díky vyrovnávací paměti jádra můžete často provádět mnoho operací (např. zápisy) bez dotazování.
Při použití jako rozhraní spouštěné okrajem je z důvodů výkonu možné přidat deskriptor souboru do rozhraní epoll (EPOLL_CTL_ADD) jednou zadáním (EPOLLIN|EPOLLOUT). To vám umožní vyhnout se nepřetržitému přepínání mezi EPOLLIN a EPOLLOUT Callepoll_ctl(2) s EPOLL_CTL_MOD.
Q9 Musím nepřetržitě číst/zapisovat deskriptor souboru, dokud EAGAIN při použití příznaku EPOLLET (chování spouštěné hranou)?
A9 Receiving an event from epoll_wait(2) should suggest to you that
such file descriptor is ready for the requested I/O operation. You
must consider it ready until the next (nonblocking) read/write
yields EAGAIN. When and how you will use the file descriptor is
entirely up to you.
For packet/token-oriented files (e.g., datagram socket, terminal in
canonical mode), the only way to detect the end of the read/write
I/O space is to continue to read/write until EAGAIN.
For stream-oriented files (e.g., pipe, FIFO, stream socket), the
condition that the read/write I/O space is exhausted can also be
detected by checking the amount of data read from / written to the
target file descriptor. For example, if you call read(2) by asking
to read a certain amount of data and read(2) returns a lower number
of bytes, you can be sure of having exhausted the read I/O space
for the file descriptor. The same is true when writing using
write(2). (Avoid this latter technique if you cannot guarantee
that the monitored file descriptor always refers to a stream-ori‐
ented file.)