| … | |
… | |
| 921 | =head2 Discussion |
921 | =head2 Discussion |
| 922 | |
922 | |
| 923 | The benchmark does I<not> measure scalability of the event loop very |
923 | The benchmark does I<not> measure scalability of the event loop very |
| 924 | well. For example, a select-based event loop (such as the pure perl one) |
924 | well. For example, a select-based event loop (such as the pure perl one) |
| 925 | can never compete with an event loop that uses epoll when the number of |
925 | can never compete with an event loop that uses epoll when the number of |
| 926 | file descriptors grows high. In this benchmark, only a single filehandle |
926 | file descriptors grows high. In this benchmark, all events become ready at |
| 927 | is used (although some of the AnyEvent adaptors dup() its file descriptor |
927 | the same time, so select/poll-based implementations get an unnatural speed |
| 928 | to worka round bugs). |
928 | boost. |
| 929 | |
929 | |
| 930 | C<EV> is the sole leader regarding speed and memory use, which are both |
930 | C<EV> is the sole leader regarding speed and memory use, which are both |
| 931 | maximal/minimal, respectively. Even when going through AnyEvent, there are |
931 | maximal/minimal, respectively. Even when going through AnyEvent, there are |
| 932 | only two event loops that use slightly less memory (the C<Event> module |
932 | only two event loops that use slightly less memory (the C<Event> module |
| 933 | natively and the pure perl backend), and no faster event models, not even |
933 | natively and the pure perl backend), and no faster event models, not even |
| … | |
… | |
| 962 | |
962 | |
| 963 | C<POE>, regardless of underlying event loop (wether using its pure perl |
963 | C<POE>, regardless of underlying event loop (wether using its pure perl |
| 964 | select-based backend or the Event module) shows abysmal performance and |
964 | select-based backend or the Event module) shows abysmal performance and |
| 965 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
965 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
| 966 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
966 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
| 967 | invocation is almost 700 times slower than with AnyEvent's pure perl |
967 | invocation is almost 900 times slower than with AnyEvent's pure perl |
| 968 | implementation. The design of the POE adaptor class in AnyEvent can not |
968 | implementation. The design of the POE adaptor class in AnyEvent can not |
| 969 | really account for this, as session creation overhead is small compared |
969 | really account for this, as session creation overhead is small compared |
| 970 | to execution of the state machine, which is coded pretty optimally within |
970 | to execution of the state machine, which is coded pretty optimally within |
| 971 | L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. |
971 | L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. |
| 972 | |
972 | |
