… | |
… | |
935 | but this was not subjetc of this benchmark. |
935 | but this was not subjetc of this benchmark. |
936 | |
936 | |
937 | The C<Event> module has a relatively high setup and callback invocation cost, |
937 | The C<Event> module has a relatively high setup and callback invocation cost, |
938 | but overall scores on the third place. |
938 | but overall scores on the third place. |
939 | |
939 | |
940 | C<Glib>'s memory usage is quite a bit bit higher, features a faster |
940 | C<Glib>'s memory usage is quite a bit bit higher, but it features a |
941 | callback invocation and overall lands in the same class as C<Event>. |
941 | faster callback invocation and overall ends up in the same class as |
|
|
942 | C<Event>. However, Glib scales extremely badly, doubling the number of |
|
|
943 | watchers increases the processing time by more than a factor of four, |
|
|
944 | making it completely unusable when using larger numbers of watchers |
|
|
945 | (note that only a single file descriptor was used in the benchmark, so |
|
|
946 | inefficiencies of C<poll> do not account for this). |
942 | |
947 | |
943 | The C<Tk> adaptor works relatively well, the fact that it crashes with |
948 | The C<Tk> adaptor works relatively well. The fact that it crashes with |
944 | more than 2000 watchers is a big setback, however, as correctness takes |
949 | more than 2000 watchers is a big setback, however, as correctness takes |
945 | precedence over speed. Nevertheless, its performance is surprising, as the |
950 | precedence over speed. Nevertheless, its performance is surprising, as the |
946 | file descriptor is dup()ed for each watcher. This shows that the dup() |
951 | file descriptor is dup()ed for each watcher. This shows that the dup() |
947 | employed by some adaptors is not a big performance issue (it does incur a |
952 | employed by some adaptors is not a big performance issue (it does incur a |
948 | hidden memory cost inside the kernel, though). |
953 | hidden memory cost inside the kernel, though). |
949 | |
954 | |
950 | C<POE>, regardless of backend (wether using its pure perl select-based |
955 | C<POE>, regardless of underlying event loop (wether using its pure perl |
951 | backend or the Event backend) shows abysmal performance and memory |
956 | select-based backend or the Event module) shows abysmal performance and |
952 | usage: Watchers use almost 30 times as much memory as EV watchers, and 10 |
957 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
953 | times as much memory as both Event or EV via AnyEvent. Watcher invocation |
958 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
954 | is almost 700 times slower as with AnyEvent's pure perl implementation. |
959 | invocation is almost 700 times slower than with AnyEvent's pure perl |
|
|
960 | implementation. The design of the POE adaptor class in AnyEvent can not |
|
|
961 | really account for this, as session creation overhead is small compared |
|
|
962 | to execution of the state machine, which is coded pretty optimally within |
|
|
963 | L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. |
955 | |
964 | |
|
|
965 | =head2 Summary |
|
|
966 | |
956 | Summary: using EV through AnyEvent is faster than any other event |
967 | Using EV through AnyEvent is faster than any other event loop, but most |
957 | loop. The overhead AnyEvent adds can be very small, and you should avoid |
968 | event loops have acceptable performance with or without AnyEvent. |
958 | POE like the plague if you want performance or reasonable memory usage. |
969 | |
|
|
970 | The overhead AnyEvent adds is usually much smaller than the overhead of |
|
|
971 | the actual event loop, only with extremely fast event loops such as the EV |
|
|
972 | adds AnyEvent significant overhead. |
|
|
973 | |
|
|
974 | And you should simply avoid POE like the plague if you want performance or |
|
|
975 | reasonable memory usage. |
959 | |
976 | |
960 | |
977 | |
961 | =head1 FORK |
978 | =head1 FORK |
962 | |
979 | |
963 | Most event libraries are not fork-safe. The ones who are usually are |
980 | Most event libraries are not fork-safe. The ones who are usually are |