Ich würde keinen großen Leistungsunterschied zwischen Edge und Level Trigger erwarten.
Für flankengetriggert müssen Sie immer den Eingabepuffer leeren, sodass Sie einen nutzlosen (nur EWOULDBLOCK zurückgebenden) recv-Systemaufruf haben. Aber für Level-Trigger könnten Sie mehr epoll_wait-Systemaufrufe verwenden. Wie die Manpage anmerkt, könnte das Vermeiden von Hunger im Level-Trigger-Modus etwas einfacher sein.
Der wirkliche Unterschied besteht darin, dass Sie, wenn Sie mehrere Threads verwenden möchten, den Edge-Triggered-Modus verwenden müssen (obwohl Sie immer noch vorsichtig sein müssen, um die Synchronisation richtig hinzubekommen).
Der Unterschied ist nur sichtbar, wenn Sie langlebige Sitzungen verwenden und aufgrund von vollen/leeren Puffern (normalerweise mit einem Proxy) gezwungen sind, ständig zu stoppen/starten. Wenn Sie dies tun, benötigen Sie meistens einen Ereignis-Cache, und wenn Ihr Ereignis-Cache Ereignisse verarbeitet, können Sie ET verwenden und den ganzen epoll_ctl(DEL)+epoll_ctl(ADD)-Tanz vermeiden. Bei kurzlebigen Sitzungen sind die Einsparungen weniger offensichtlich, da Sie für ET mindestens einen epoll_ctl(ADD)-Aufruf benötigen, um das Abfragen auf dem FD zu aktivieren, und wenn Sie nicht erwarten, während der Lebensdauer der Sitzung mehr davon zu haben (z. B.:Börsen sind die meiste Zeit kleiner als Puffer), dann sollten Sie keinen Unterschied erwarten. Die meisten Einsparungen erzielen Sie im Allgemeinen nur durch die Verwendung eines Ereignis-Cache, da Sie dank Kernel-Puffer oft viele Operationen (z. B. Schreiben) ohne Abfrage ausführen können.
Bei Verwendung als flankengetriggerte Schnittstelle ist es aus Leistungsgründen möglich, den Dateideskriptor innerhalb der epoll-Schnittstelle (EPOLL_CTL_ADD) einmal hinzuzufügen, indem (EPOLLIN|EPOLLOUT) angegeben wird. Dadurch können Sie vermeiden, ständig zwischen EPOLLIN und EPOLOUT umzuschalten, indem Sie epoll_ctl(2) mit EPOLL_CTL_MOD aufrufen.
F9 Muss ich einen Dateideskriptor bis EAGAIN kontinuierlich lesen/schreiben, wenn ich das EPOLLET-Flag verwende (flankengetriggertes Verhalten)?
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.)