Saya tidak berharap melihat perbedaan performa yang besar antara edge dan level yang dipicu.
Untuk edge-triggered Anda selalu harus menguras buffer input, jadi Anda memiliki satu recv syscall yang tidak berguna (baru saja mengembalikan EWOULDBLOCK). Tetapi untuk level yang dipicu, Anda mungkin menggunakan lebih banyak syscall epoll_wait. Seperti yang ditunjukkan halaman manual, menghindari kelaparan mungkin sedikit lebih mudah dalam mode pemicu level.
Perbedaan sebenarnya adalah ketika Anda ingin menggunakan beberapa utas, Anda harus menggunakan mode yang dipicu tepi (meskipun Anda masih harus berhati-hati untuk mendapatkan sinkronisasi yang benar).
Perbedaannya hanya terlihat ketika Anda menggunakan sesi yang berumur panjang dan Anda dipaksa untuk terus berhenti/memulai karena buffer penuh/kosong (biasanya dengan proxy). Saat Anda melakukan ini, Anda paling sering memerlukan cache peristiwa, dan saat cache peristiwa memproses peristiwa, Anda dapat menggunakan ET dan menghindari semua tarian epoll_ctl(DEL)+epoll_ctl(ADD). Untuk sesi yang berumur pendek, penghematannya kurang jelas, karena untuk ET Anda memerlukan setidaknya satu panggilan epoll_ctl(ADD) untuk mengaktifkan polling di FD, dan jika Anda tidak berharap memiliki lebih banyak panggilan selama masa pakai sesi (mis:sebagian besar pertukaran lebih kecil dari buffer), maka Anda seharusnya tidak mengharapkan perbedaan apa pun. Sebagian besar penghematan Anda umumnya berasal dari penggunaan cache peristiwa saja karena Anda sering dapat melakukan banyak operasi (misalnya:menulis) tanpa polling berkat buffer kernel.
Ketika digunakan sebagai antarmuka yang dipicu tepi, untuk alasan kinerja, dimungkinkan untuk menambahkan deskriptor file di dalam antarmuka epoll (EPOLL_CTL_ADD) satu kali dengan menentukan (EPOLLIN|EPOLLOUT). Hal ini memungkinkan Anda untuk menghindari terus beralih antara panggilan EPOLLIN dan EPOLLOUT epoll_ctl(2) dengan EPOLL_CTL_MOD.
T9 Apakah saya harus terus membaca/menulis deskriptor file hingga EAGAINketika menggunakan bendera EPOLLET (perilaku yang dipicu tepi)?
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.)