… | |
… | |
964 | maximal/minimal, respectively. Even when going through AnyEvent, it uses |
964 | maximal/minimal, respectively. Even when going through AnyEvent, it uses |
965 | far less memory than any other event loop and is still faster than Event |
965 | far less memory than any other event loop and is still faster than Event |
966 | natively. |
966 | natively. |
967 | |
967 | |
968 | The pure perl implementation is hit in a few sweet spots (both the |
968 | The pure perl implementation is hit in a few sweet spots (both the |
969 | zero timeout and the use of a single fd hit optimisations in the perl |
969 | constant timeout and the use of a single fd hit optimisations in the perl |
970 | interpreter and the backend itself, and all watchers become ready at the |
970 | interpreter and the backend itself). Nevertheless this shows that it |
971 | same time). Nevertheless this shows that it adds very little overhead in |
971 | adds very little overhead in itself. Like any select-based backend its |
972 | itself. Like any select-based backend its performance becomes really bad |
972 | performance becomes really bad with lots of file descriptors (and few of |
973 | with lots of file descriptors (and few of them active), of course, but |
973 | them active), of course, but this was not subject of this benchmark. |
974 | this was not subject of this benchmark. |
|
|
975 | |
974 | |
976 | The C<Event> module has a relatively high setup and callback invocation cost, |
975 | The C<Event> module has a relatively high setup and callback invocation cost, |
977 | but overall scores on the third place. |
976 | but overall scores on the third place. |
978 | |
977 | |
979 | C<Glib>'s memory usage is quite a bit bit higher, but it features a |
978 | C<Glib>'s memory usage is quite a bit bit higher, but it features a |
… | |
… | |
990 | file descriptor is dup()ed for each watcher. This shows that the dup() |
989 | file descriptor is dup()ed for each watcher. This shows that the dup() |
991 | employed by some adaptors is not a big performance issue (it does incur a |
990 | employed by some adaptors is not a big performance issue (it does incur a |
992 | hidden memory cost inside the kernel, though, that is not reflected in the |
991 | hidden memory cost inside the kernel, though, that is not reflected in the |
993 | figures above). |
992 | figures above). |
994 | |
993 | |
995 | C<POE>, regardless of underlying event loop (wether using its pure perl |
994 | C<POE>, regardless of underlying event loop (whether using its pure perl |
996 | select-based backend or the Event module) shows abysmal performance and |
995 | select-based backend or the Event module) shows abysmal performance and |
997 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
996 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
998 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
997 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
999 | invocation is almost 900 times slower than with AnyEvent's pure perl |
998 | invocation is almost 900 times slower than with AnyEvent's pure perl |
1000 | implementation. The design of the POE adaptor class in AnyEvent can not |
999 | implementation. The design of the POE adaptor class in AnyEvent can not |