| … | |
… | |
| 970 | interpreter and the backend itself). Nevertheless this shows that it |
970 | interpreter and the backend itself). Nevertheless this shows that it |
| 971 | adds very little overhead in itself. Like any select-based backend its |
971 | adds very little overhead in itself. Like any select-based backend its |
| 972 | performance becomes really bad with lots of file descriptors (and few of |
972 | performance becomes really bad with lots of file descriptors (and few of |
| 973 | them active), of course, but this was not subject of this benchmark. |
973 | them active), of course, but this was not subject of this benchmark. |
| 974 | |
974 | |
| 975 | 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 |
| 976 | but overall scores on the third place. |
976 | cost, but overall scores in on the third place. |
| 977 | |
977 | |
| 978 | 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 higher, but it features a |
| 979 | faster callback invocation and overall ends up in the same class as |
979 | faster callback invocation and overall ends up in the same class as |
| 980 | C<Event>. However, Glib scales extremely badly, doubling the number of |
980 | C<Event>. However, Glib scales extremely badly, doubling the number of |
| 981 | watchers increases the processing time by more than a factor of four, |
981 | watchers increases the processing time by more than a factor of four, |
| 982 | making it completely unusable when using larger numbers of watchers |
982 | making it completely unusable when using larger numbers of watchers |
| 983 | (note that only a single file descriptor was used in the benchmark, so |
983 | (note that only a single file descriptor was used in the benchmark, so |
| … | |
… | |
| 1005 | |
1005 | |
| 1006 | =head2 Summary |
1006 | =head2 Summary |
| 1007 | |
1007 | |
| 1008 | =over 4 |
1008 | =over 4 |
| 1009 | |
1009 | |
| 1010 | =item * Using EV through AnyEvent is faster than any other event loop, but most |
1010 | =item * Using EV through AnyEvent is faster than any other event loop |
| 1011 | event loops have acceptable performance with or without AnyEvent. |
1011 | (even when used without AnyEvent), but most event loops have acceptable |
|
|
1012 | performance with or without AnyEvent. |
| 1012 | |
1013 | |
| 1013 | =item * The overhead AnyEvent adds is usually much smaller than the overhead of |
1014 | =item * The overhead AnyEvent adds is usually much smaller than the overhead of |
| 1014 | the actual event loop, only with extremely fast event loops such as the EV |
1015 | the actual event loop, only with extremely fast event loops such as EV |
| 1015 | adds AnyEvent significant overhead. |
1016 | adds AnyEvent significant overhead. |
| 1016 | |
1017 | |
| 1017 | =item * And you should simply avoid POE like the plague if you want performance or |
1018 | =item * You should avoid POE like the plague if you want performance or |
| 1018 | reasonable memory usage. |
1019 | reasonable memory usage. |
| 1019 | |
1020 | |
| 1020 | =back |
1021 | =back |
| 1021 | |
1022 | |
| 1022 | |
1023 | |
