No esperaría ver una gran diferencia de rendimiento entre el borde y el nivel activado.
Para la activación por borde, siempre tiene que drenar el búfer de entrada, por lo que tiene una llamada al sistema recv inútil (que solo devuelve EWOULDBLOCK). Pero para el nivel activado, puede usar más llamadas al sistema epoll_wait. Como señala la página de manual, evitar morir de hambre puede ser un poco más fácil en el modo activado por nivel.
La verdadera diferencia es que cuando desee utilizar varios subprocesos, tendrá que utilizar el modo activado por borde (aunque aún tendrá que tener cuidado con la sincronización correcta).
La diferencia solo es visible cuando usa sesiones de larga duración y se ve obligado a detenerse/iniciar constantemente debido a los búferes llenos/vacíos (normalmente con un proxy). Cuando hace esto, lo más frecuente es que necesite un caché de eventos, y cuando su caché de eventos está procesando eventos, puede usar ET y evitar todo el baile epoll_ctl(DEL)+epoll_ctl(ADD). Para sesiones de corta duración, los ahorros son menos obvios, porque para ET necesitará al menos una llamada epoll_ctl(ADD) para habilitar el sondeo en el FD, y si no espera tener más de ellos durante la vida de la sesión (por ejemplo:los intercambios son más pequeños que los búferes la mayor parte del tiempo), entonces no debe esperar ninguna diferencia. La mayoría de sus ahorros generalmente provendrán del uso de un caché de eventos solo, ya que a menudo puede realizar muchas operaciones (por ejemplo, escrituras) sin encuestas gracias a los búferes del kernel.
Cuando se utiliza como una interfaz activada por borde, por razones de rendimiento, es posible agregar el descriptor de archivo dentro de la interfaz epoll (EPOLL_CTL_ADD) una vez especificando (EPOLLIN|EPOLLOUT). Esto le permite evitar cambiar continuamente entre EPOLLIN y EPOLLOUT llamando apoll_ctl(2) con EPOLL_CTL_MOD.
P9 ¿Necesito leer/escribir continuamente un descriptor de archivo hasta EAGAIN al usar el indicador EPOLLET (comportamiento activado por borde)?
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.)