| … | |
… | |
| 959 | can never compete with an event loop that uses epoll when the number of |
959 | can never compete with an event loop that uses epoll when the number of |
| 960 | file descriptors grows high. In this benchmark, all events become ready at |
960 | file descriptors grows high. In this benchmark, all events become ready at |
| 961 | the same time, so select/poll-based implementations get an unnatural speed |
961 | the same time, so select/poll-based implementations get an unnatural speed |
| 962 | boost. |
962 | boost. |
| 963 | |
963 | |
|
|
964 | Also, note that the number of watchers usually has a nonlinear effect on |
|
|
965 | overall speed, that is, creating twice as many watchers doesn't take twice |
|
|
966 | the time - usually it takes longer. This puts event loops tested with a |
|
|
967 | higher number of watchers at a disadvantage. |
|
|
968 | |
|
|
969 | To put the range of results into perspective, consider that on the |
|
|
970 | benchmark machine, handling an event takes roughly 1600 CPU cycles with |
|
|
971 | EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU |
|
|
972 | cycles with POE. |
|
|
973 | |
| 964 | C<EV> is the sole leader regarding speed and memory use, which are both |
974 | C<EV> is the sole leader regarding speed and memory use, which are both |
| 965 | maximal/minimal, respectively. Even when going through AnyEvent, it uses |
975 | maximal/minimal, respectively. Even when going through AnyEvent, it uses |
| 966 | far less memory than any other event loop and is still faster than Event |
976 | far less memory than any other event loop and is still faster than Event |
| 967 | natively. |
977 | natively. |
| 968 | |
978 | |
