Non mi aspetto di vedere un'enorme differenza di prestazioni tra edge e level triggered.
Per edge-triggered devi sempre svuotare il buffer di input, quindi hai una syscall recv inutile (restituendo solo EWOULDBLOCK). Ma per il livello attivato potresti usare più chiamate di sistema epoll_wait. Come sottolinea la pagina man, evitare la fame potrebbe essere leggermente più semplice nella modalità attivata dal livello.
La vera differenza è che quando vuoi utilizzare più thread dovrai usare la modalità edge-triggered (anche se dovrai comunque stare attento a ottenere la sincronizzazione corretta).
La differenza è visibile solo quando si utilizzano sessioni di lunga durata e si è costretti a interrompere/avviare costantemente a causa di buffer pieni/vuoti (tipicamente con un proxy). Quando lo fai, molto spesso hai bisogno di una cache di eventi e quando la tua cache di eventi sta elaborando eventi, puoi usare ET ed evitare tutto il ballo epoll_ctl(DEL)+epoll_ctl(ADD). Per le sessioni di breve durata, i risparmi sono meno evidenti, perché per ET avrai bisogno di almeno una chiamata epoll_ctl(ADD) per abilitare il polling sull'FD, e se non ti aspetti di averne di più durante la vita della sessione (ad esempio:gli scambi sono più piccoli dei buffer per la maggior parte del tempo), quindi non dovresti aspettarti alcuna differenza. La maggior parte dei tuoi risparmi proverrà generalmente dall'utilizzo di una cache degli eventi poiché spesso puoi eseguire molte operazioni (ad esempio:scritture) senza eseguire il polling grazie ai buffer del kernel.
Se utilizzata come interfaccia edge-triggered, per motivi di prestazioni, è possibile aggiungere una volta il descrittore di file all'interno dell'interfaccia epoll (EPOLL_CTL_ADD) specificando (EPOLLIN|EPOLLOUT). Ciò consente di evitare di passare continuamente da EPOLLIN a EPOLLOUT chiamando epoll_ctl(2) con EPOLL_CTL_MOD.
D9 Devo leggere/scrivere continuamente un descrittore di file fino a EAGAINquando utilizzo il flag EPOLLET (comportamento attivato dall'edge)?
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.)