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.95 by root, Sat Apr 26 11:06:45 2008 UTC vs.
Revision 1.103 by root, Tue Apr 29 07:15:49 2008 UTC

… …
65technically possible. 65technically possible.
66 66
67Of course, if you want lots of policy (this can arguably be somewhat 67Of course, if you want lots of policy (this can arguably be somewhat
68useful) and you want to force your users to use the one and only event 68useful) and you want to force your users to use the one and only event
69model, you should I<not> use this module. 69model, you should I<not> use this module.
70
71 70
72=head1 DESCRIPTION 71=head1 DESCRIPTION
73 72
74L<AnyEvent> provides an identical interface to multiple event loops. This 73L<AnyEvent> provides an identical interface to multiple event loops. This
75allows module authors to utilise an event loop without forcing module 74allows module authors to utilise an event loop without forcing module
… …
457might chose the wrong one unless you load the correct one yourself. 456might chose the wrong one unless you load the correct one yourself.
458 457
459You can chose to use a rather inefficient pure-perl implementation by 458You can chose to use a rather inefficient pure-perl implementation by
460loading the C<AnyEvent::Impl::Perl> module, which gives you similar 459loading the C<AnyEvent::Impl::Perl> module, which gives you similar
461behaviour everywhere, but letting AnyEvent chose is generally better. 460behaviour everywhere, but letting AnyEvent chose is generally better.
461
462=head1 OTHER MODULES
463
464The following is a non-exhaustive list of additional modules that use
465AnyEvent and can therefore be mixed easily with other AnyEvent modules
466in the same program. Some of the modules come with AnyEvent, some are
467available via CPAN.
468
469=over 4
470
471=item L<AnyEvent::Util>
472
473Contains various utility functions that replace often-used but blocking
474functions such as C<inet_aton> by event-/callback-based versions.
475
476=item L<AnyEvent::Handle>
477
478Provide read and write buffers and manages watchers for reads and writes.
479
480=item L<AnyEvent::Socket>
481
482Provides a means to do non-blocking connects, accepts etc.
483
484=item L<AnyEvent::HTTPD>
485
486Provides a simple web application server framework.
487
488=item L<AnyEvent::DNS>
489
490Provides asynchronous DNS resolver capabilities, beyond what
491L<AnyEvent::Util> offers.
492
493=item L<AnyEvent::FastPing>
494
495The fastest ping in the west.
496
497=item L<Net::IRC3>
498
499AnyEvent based IRC client module family.
500
501=item L<Net::XMPP2>
502
503AnyEvent based XMPP (Jabber protocol) module family.
504
505=item L<Net::FCP>
506
507AnyEvent-based implementation of the Freenet Client Protocol, birthplace
508of AnyEvent.
509
510=item L<Event::ExecFlow>
511
512High level API for event-based execution flow control.
513
514=item L<Coro>
515
516Has special support for AnyEvent.
517
518=item L<IO::Lambda>
519
520The lambda approach to I/O - don't ask, look there. Can use AnyEvent.
521
522=item L<IO::AIO>
523
524Truly asynchronous I/O, should be in the toolbox of every event
525programmer. Can be trivially made to use AnyEvent.
526
527=item L<BDB>
528
529Truly asynchronous Berkeley DB access. Can be trivially made to use
530AnyEvent.
531
532=back
462 533
463=cut 534=cut
464 535
465package AnyEvent; 536package AnyEvent;
466 537
… …
944 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 1015 EV/EV 400000 244 0.56 0.46 0.31 EV native interface
945 EV/Any 100000 244 2.50 0.46 0.29 EV + AnyEvent watchers 1016 EV/Any 100000 244 2.50 0.46 0.29 EV + AnyEvent watchers
946 CoroEV/Any 100000 244 2.49 0.44 0.29 coroutines + Coro::Signal 1017 CoroEV/Any 100000 244 2.49 0.44 0.29 coroutines + Coro::Signal
947 Perl/Any 100000 513 4.92 0.87 1.12 pure perl implementation 1018 Perl/Any 100000 513 4.92 0.87 1.12 pure perl implementation
948 Event/Event 16000 516 31.88 31.30 0.85 Event native interface 1019 Event/Event 16000 516 31.88 31.30 0.85 Event native interface
949 Event/Any 16000 936 39.17 33.63 1.43 Event + AnyEvent watchers 1020 Event/Any 16000 590 35.75 31.42 1.08 Event + AnyEvent watchers
950 Glib/Any 16000 1357 98.22 12.41 54.00 quadratic behaviour 1021 Glib/Any 16000 1357 98.22 12.41 54.00 quadratic behaviour
951 Tk/Any 2000 1860 26.97 67.98 14.00 SEGV with >> 2000 watchers 1022 Tk/Any 2000 1860 26.97 67.98 14.00 SEGV with >> 2000 watchers
952 POE/Event 2000 6644 108.64 736.02 14.73 via POE::Loop::Event 1023 POE/Event 2000 6644 108.64 736.02 14.73 via POE::Loop::Event
953 POE/Select 2000 6343 94.13 809.12 565.96 via POE::Loop::Select 1024 POE/Select 2000 6343 94.13 809.12 565.96 via POE::Loop::Select
954 1025
… …
963 1034
964Also, note that the number of watchers usually has a nonlinear effect on 1035Also, 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 1036overall 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 1037the time - usually it takes longer. This puts event loops tested with a
967higher number of watchers at a disadvantage. 1038higher number of watchers at a disadvantage.
1039
1040To put the range of results into perspective, consider that on the
1041benchmark machine, handling an event takes roughly 1600 CPU cycles with
1042EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU
1043cycles with POE.
968 1044
969C<EV> is the sole leader regarding speed and memory use, which are both 1045C<EV> is the sole leader regarding speed and memory use, which are both
970maximal/minimal, respectively. Even when going through AnyEvent, it uses 1046maximal/minimal, respectively. Even when going through AnyEvent, it uses
971far less memory than any other event loop and is still faster than Event 1047far less memory than any other event loop and is still faster than Event
972natively. 1048natively.
… …
995file descriptor is dup()ed for each watcher. This shows that the dup() 1071file descriptor is dup()ed for each watcher. This shows that the dup()
996employed by some adaptors is not a big performance issue (it does incur a 1072employed by some adaptors is not a big performance issue (it does incur a
997hidden memory cost inside the kernel which is not reflected in the figures 1073hidden memory cost inside the kernel which is not reflected in the figures
998above). 1074above).
999 1075
1000C<POE>, regardless of underlying event loop (whether using its pure 1076C<POE>, regardless of underlying event loop (whether using its pure perl
1001perl select-based backend or the Event module, the POE-EV backend 1077select-based backend or the Event module, the POE-EV backend couldn't
1002couldn't be tested because it wasn't working) shows abysmal performance 1078be tested because it wasn't working) shows abysmal performance and
1003and memory usage: Watchers use almost 30 times as much memory as 1079memory usage with AnyEvent: Watchers use almost 30 times as much memory
1004EV watchers, and 10 times as much memory as Event (the high memory 1080as EV watchers, and 10 times as much memory as Event (the high memory
1005requirements are caused by requiring a session for each watcher). Watcher 1081requirements are caused by requiring a session for each watcher). Watcher
1006invocation speed is almost 900 times slower than with AnyEvent's pure perl 1082invocation speed is almost 900 times slower than with AnyEvent's pure perl
1083implementation.
1084
1007implementation. The design of the POE adaptor class in AnyEvent can not 1085The design of the POE adaptor class in AnyEvent can not really account
1008really account for this, as session creation overhead is small compared 1086for the performance issues, though, as session creation overhead is
1009to execution of the state machine, which is coded pretty optimally within 1087small compared to execution of the state machine, which is coded pretty
1010L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. 1088optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that
1089using multiple sessions is not a good approach, especially regarding
1090memory usage, even the author of POE could not come up with a faster
1091design).
1011 1092
1012=head3 Summary 1093=head3 Summary
1013 1094
1014=over 4 1095=over 4
1015 1096
… …
1062 1143
1063=head3 Results 1144=head3 Results
1064 1145
1065 name sockets create request 1146 name sockets create request
1066 EV 20000 69.01 11.16 1147 EV 20000 69.01 11.16
1067 Perl 20000 75.28 112.76 1148 Perl 20000 73.32 35.87
1068 Event 20000 212.62 257.32 1149 Event 20000 212.62 257.32
1069 Glib 20000 651.16 1896.30 1150 Glib 20000 651.16 1896.30
1070 POE 20000 349.67 12317.24 uses POE::Loop::Event 1151 POE 20000 349.67 12317.24 uses POE::Loop::Event
1071 1152
1072=head3 Discussion 1153=head3 Discussion
… …
1094 1175
1095=head3 Summary 1176=head3 Summary
1096 1177
1097=over 4 1178=over 4
1098 1179
1099=item * The pure perl implementation performs extremely well, considering 1180=item * The pure perl implementation performs extremely well.
1100that it uses select.
1101 1181
1102=item * Avoid Glib or POE in large projects where performance matters. 1182=item * Avoid Glib or POE in large projects where performance matters.
1103 1183
1104=back 1184=back
1105 1185
… …
1118 1198
1119=head3 Results 1199=head3 Results
1120 1200
1121 name sockets create request 1201 name sockets create request
1122 EV 16 20.00 6.54 1202 EV 16 20.00 6.54
1203 Perl 16 25.75 12.62
1123 Event 16 81.27 35.86 1204 Event 16 81.27 35.86
1124 Glib 16 32.63 15.48 1205 Glib 16 32.63 15.48
1125 Perl 16 24.62 162.37
1126 POE 16 261.87 276.28 uses POE::Loop::Event 1206 POE 16 261.87 276.28 uses POE::Loop::Event
1127 1207
1128=head3 Discussion 1208=head3 Discussion
1129 1209
1130The benchmark tries to test the performance of a typical small 1210The benchmark tries to test the performance of a typical small
1131server. While knowing how various event loops perform is interesting, keep 1211server. While knowing how various event loops perform is interesting, keep
1132in mind that their overhead in this case is usually not as important, due 1212in mind that their overhead in this case is usually not as important, due
1133to the small absolute number of watchers. 1213to the small absolute number of watchers (that is, you need efficiency and
1214speed most when you have lots of watchers, not when you only have a few of
1215them).
1134 1216
1135EV is again fastest. 1217EV is again fastest.
1136 1218
1137The C-based event loops Event and Glib come in second this time, as the 1219Perl again comes second. It is noticably faster than the C-based event
1138overhead of running an iteration is much smaller in C than in Perl (little 1220loops Event and Glib, although the difference is too small to really
1139code to execute in the inner loop, and perl's function calling overhead is 1221matter.
1140high, and updating all the data structures is costly).
1141 1222
1142The pure perl event loop is much slower, but still competitive.
1143
1144POE also performs much better in this case, but is is stillf ar behind the 1223POE also performs much better in this case, but is is still far behind the
1145others. 1224others.
1146 1225
1147=head3 Summary 1226=head3 Summary
1148 1227
1149=over 4 1228=over 4

Diff Legend

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