… | |
… | |
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 | |
… | |
… | |
1123 | =head3 Discussion |
1133 | =head3 Discussion |
1124 | |
1134 | |
1125 | The benchmark tries to test the performance of a typical small |
1135 | The benchmark tries to test the performance of a typical small |
1126 | server. While knowing how various event loops perform is interesting, keep |
1136 | server. While knowing how various event loops perform is interesting, keep |
1127 | in mind that their overhead in this case is usually not as important, due |
1137 | in mind that their overhead in this case is usually not as important, due |
1128 | to the small absolute number of watchers. |
1138 | to the small absolute number of watchers (that is, you need efficiency and |
|
|
1139 | speed most when you have lots of watchers, not when you only have a few of |
|
|
1140 | them). |
1129 | |
1141 | |
1130 | EV is again fastest. |
1142 | EV is again fastest. |
1131 | |
1143 | |
1132 | The C-based event loops Event and Glib come in second this time, as the |
1144 | The C-based event loops Event and Glib come in second this time, as the |
1133 | overhead of running an iteration is much smaller in C than in Perl (little |
1145 | overhead of running an iteration is much smaller in C than in Perl (little |
1134 | code to execute in the inner loop, and perl's function calling overhead is |
1146 | code to execute in the inner loop, and perl's function calling overhead is |
1135 | high, and updating all the data structures is costly). |
1147 | high, and updating all the data structures is costly). |
1136 | |
1148 | |
1137 | The pure perl event loop is much slower, but still competitive. |
1149 | The pure perl event loop is much slower, but still competitive. |
1138 | |
1150 | |
1139 | POE also performs much better in this case, but is is stillf ar behind the |
1151 | POE also performs much better in this case, but is is still far behind the |
1140 | others. |
1152 | others. |
1141 | |
1153 | |
1142 | =head3 Summary |
1154 | =head3 Summary |
1143 | |
1155 | |
1144 | =over 4 |
1156 | =over 4 |