ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent/lib/AnyEvent.pm
(Generate patch)

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.91 by root, Sat Apr 26 02:27:30 2008 UTC vs.
Revision 1.97 by root, Sun Apr 27 03:31:53 2008 UTC

… …
959can never compete with an event loop that uses epoll when the number of 959can never compete with an event loop that uses epoll when the number of
960file descriptors grows high. In this benchmark, all events become ready at 960file descriptors grows high. In this benchmark, all events become ready at
961the same time, so select/poll-based implementations get an unnatural speed 961the same time, so select/poll-based implementations get an unnatural speed
962boost. 962boost.
963 963
964Also, note that the number of watchers usually has a nonlinear effect on
965overall speed, that is, creating twice as many watchers doesn't take twice
966the time - usually it takes longer. This puts event loops tested with a
967higher number of watchers at a disadvantage.
968
969To put the range of results into perspective, consider that on the
970benchmark machine, handling an event takes roughly 1600 CPU cycles with
971EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU
972cycles with POE.
973
964C<EV> is the sole leader regarding speed and memory use, which are both 974C<EV> is the sole leader regarding speed and memory use, which are both
965maximal/minimal, respectively. Even when going through AnyEvent, it uses 975maximal/minimal, respectively. Even when going through AnyEvent, it uses
966far less memory than any other event loop and is still faster than Event 976far less memory than any other event loop and is still faster than Event
967natively. 977natively.
968 978
… …
1035timeout is reset each time something is read because that reflects how 1045timeout is reset each time something is read because that reflects how
1036most timeouts work (and puts extra pressure on the event loops). 1046most timeouts work (and puts extra pressure on the event loops).
1037 1047
1038In this benchmark, we use 10000 socketpairs (20000 sockets), of which 100 1048In this benchmark, we use 10000 socketpairs (20000 sockets), of which 100
1039(1%) are active. This mirrors the activity of large servers with many 1049(1%) are active. This mirrors the activity of large servers with many
1040connections, most of which are idle during at any one point in time. 1050connections, most of which are idle at any one point in time.
1041 1051
1042Source code for this benchmark is found as F<eg/bench2> in the AnyEvent 1052Source code for this benchmark is found as F<eg/bench2> in the AnyEvent
1043distribution. 1053distribution.
1044 1054
1045=head3 Explanation of the columns 1055=head3 Explanation of the columns
1046 1056
1047I<sockets> is the number of sockets, and twice the number of "servers" (as 1057I<sockets> is the number of sockets, and twice the number of "servers" (as
1048eahc server has a read and write socket end). 1058each server has a read and write socket end).
1049 1059
1050I<create> is the time it takes to create a socketpair (which is 1060I<create> is the time it takes to create a socketpair (which is
1051nontrivial) and two watchers: an I/O watcher and a timeout watcher. 1061nontrivial) and two watchers: an I/O watcher and a timeout watcher.
1052 1062
1053I<request>, the most important value, is the time it takes to handle a 1063I<request>, the most important value, is the time it takes to handle a
1054single "request", that is, reading the token from the pipe and forwarding 1064single "request", that is, reading the token from the pipe and forwarding
1055it to another server. This includes deleteing the old timeout and creating 1065it to another server. This includes deleting the old timeout and creating
1056a new one with a later timeout. 1066a new one that moves the timeout into the future.
1057 1067
1058=head3 Results 1068=head3 Results
1059 1069
1060 name sockets create request 1070 name sockets create request
1061 EV 20000 69.01 11.16 1071 EV 20000 69.01 11.16
… …
1123=head3 Discussion 1133=head3 Discussion
1124 1134
1125The benchmark tries to test the performance of a typical small 1135The benchmark tries to test the performance of a typical small
1126server. While knowing how various event loops perform is interesting, keep 1136server. While knowing how various event loops perform is interesting, keep
1127in mind that their overhead in this case is usually not as important, due 1137in mind that their overhead in this case is usually not as important, due
1128to the small absolute number of watchers. 1138to the small absolute number of watchers (that is, you need efficiency and
1139speed most when you have lots of watchers, not when you only have a few of
1140them).
1129 1141
1130EV is again fastest. 1142EV is again fastest.
1131 1143
1132The C-based event loops Event and Glib come in second this time, as the 1144The C-based event loops Event and Glib come in second this time, as the
1133overhead of running an iteration is much smaller in C than in Perl (little 1145overhead of running an iteration is much smaller in C than in Perl (little
1134code to execute in the inner loop, and perl's function calling overhead is 1146code to execute in the inner loop, and perl's function calling overhead is
1135high, and updating all the data structures is costly). 1147high, and updating all the data structures is costly).
1136 1148
1137The pure perl event loop is much slower, but still competitive. 1149The pure perl event loop is much slower, but still competitive.
1138 1150
1139POE also performs much better in this case, but is is stillf ar behind the 1151POE also performs much better in this case, but is is still far behind the
1140others. 1152others.
1141 1153
1142=head3 Summary 1154=head3 Summary
1143 1155
1144=over 4 1156=over 4

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines