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.73 by root, Fri Apr 25 07:47:12 2008 UTC vs.
Revision 1.79 by root, Fri Apr 25 09:08:16 2008 UTC

… …
136 136
137Note that C<my $w; $w => combination. This is necessary because in Perl, 137Note that C<my $w; $w => combination. This is necessary because in Perl,
138my variables are only visible after the statement in which they are 138my variables are only visible after the statement in which they are
139declared. 139declared.
140 140
141=head2 IO WATCHERS 141=head2 I/O WATCHERS
142 142
143You can create an I/O watcher by calling the C<< AnyEvent->io >> method 143You can create an I/O watcher by calling the C<< AnyEvent->io >> method
144with the following mandatory key-value pairs as arguments: 144with the following mandatory key-value pairs as arguments:
145 145
146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for 146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for
… …
706 706
707=back 707=back
708 708
709=head1 EXAMPLE PROGRAM 709=head1 EXAMPLE PROGRAM
710 710
711The following program uses an IO watcher to read data from STDIN, a timer 711The following program uses an I/O watcher to read data from STDIN, a timer
712to display a message once per second, and a condition variable to quit the 712to display a message once per second, and a condition variable to quit the
713program when the user enters quit: 713program when the user enters quit:
714 714
715 use AnyEvent; 715 use AnyEvent;
716 716
… …
867 867
868To give you an idea of the performance and overheads that AnyEvent adds 868To give you an idea of the performance and overheads that AnyEvent adds
869over the event loops themselves (and to give you an impression of the 869over the event loops themselves (and to give you an impression of the
870speed of various event loops), here is a benchmark of various supported 870speed of various event loops), here is a benchmark of various supported
871event models natively and with anyevent. The benchmark creates a lot of 871event models natively and with anyevent. The benchmark creates a lot of
872timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to 872timers (with a zero timeout) and I/O watchers (watching STDOUT, a pty, to
873become writable, which it is), lets them fire exactly once and destroys 873become writable, which it is), lets them fire exactly once and destroys
874them again. 874them again.
875
876Rewriting the benchmark to use many different sockets instead of using
877the same filehandle for all I/O watchers results in a much longer runtime
878(socket creation is expensive), but qualitatively the same figures, so it
879was not used.
875 880
876=head2 Explanation of the columns 881=head2 Explanation of the columns
877 882
878I<watcher> is the number of event watchers created/destroyed. Since 883I<watcher> is the number of event watchers created/destroyed. Since
879different event models feature vastly different performances, each event 884different event models feature vastly different performances, each event
… …
899I<destroy> is the time, in microseconds, that it takes to destroy a single 904I<destroy> is the time, in microseconds, that it takes to destroy a single
900watcher. 905watcher.
901 906
902=head2 Results 907=head2 Results
903 908
904 name watcher bytes create invoke destroy comment 909 name watchers bytes create invoke destroy comment
905 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 910 EV/EV 400000 244 0.56 0.46 0.31 EV native interface
906 EV/Any 100000 610 3.52 0.91 0.75 EV + AnyEvent watchers 911 EV/Any 100000 610 3.52 0.91 0.75 EV + AnyEvent watchers
907 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal 912 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal
908 Perl/Any 16000 654 4.64 1.22 0.77 pure perl implementation 913 Perl/Any 100000 513 4.91 0.92 1.15 pure perl implementation
909 Event/Event 16000 523 28.05 21.38 0.86 Event native interface 914 Event/Event 16000 523 28.05 21.38 0.86 Event native interface
910 Event/Any 16000 943 34.43 20.48 1.39 Event + AnyEvent watchers 915 Event/Any 16000 943 34.43 20.48 1.39 Event + AnyEvent watchers
911 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour 916 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour
912 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers 917 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers
913 POE/Event 2000 6644 108.15 768.19 14.33 via POE::Loop::Event 918 POE/Event 2000 6644 108.15 768.19 14.33 via POE::Loop::Event
914 POE/Select 2000 6343 94.69 807.65 562.69 via POE::Loop::Select 919 POE/Select 2000 6343 94.69 807.65 562.69 via POE::Loop::Select
915 920
916=head2 Discussion 921=head2 Discussion
917 922
918The benchmark does I<not> measure scalability of the event loop very 923The benchmark does I<not> measure scalability of the event loop very
919well. For example, a select-based event loop (such as the pure perl one) 924well. For example, a select-based event loop (such as the pure perl one)
… …
921file descriptors grows high. In this benchmark, only a single filehandle 926file descriptors grows high. In this benchmark, only a single filehandle
922is used (although some of the AnyEvent adaptors dup() its file descriptor 927is used (although some of the AnyEvent adaptors dup() its file descriptor
923to worka round bugs). 928to worka round bugs).
924 929
925C<EV> is the sole leader regarding speed and memory use, which are both 930C<EV> is the sole leader regarding speed and memory use, which are both
926maximal/minimal, respectively. Even when going through AnyEvent, there is 931maximal/minimal, respectively. Even when going through AnyEvent, there are
927only one event loop that uses less memory (the C<Event> module natively), and 932only two event loops that use slightly less memory (the C<Event> module
928no faster event model, not event C<Event> natively. 933natively and the pure perl backend), and no faster event models, not even
934C<Event> natively.
929 935
930The pure perl implementation is hit in a few sweet spots (both the 936The pure perl implementation is hit in a few sweet spots (both the
931zero timeout and the use of a single fd hit optimisations in the perl 937zero timeout and the use of a single fd hit optimisations in the perl
932interpreter and the backend itself). Nevertheless tis shows that it 938interpreter and the backend itself, and all watchers become ready at the
933adds very little overhead in itself. Like any select-based backend its 939same time). Nevertheless this shows that it adds very little overhead in
934performance becomes really bad with lots of file descriptors, of course, 940itself. Like any select-based backend its performance becomes really bad
941with lots of file descriptors (and few of them active), of course, but
935but this was not subjetc of this benchmark. 942this was not subject of this benchmark.
936 943
937The C<Event> module has a relatively high setup and callback invocation cost, 944The C<Event> module has a relatively high setup and callback invocation cost,
938but overall scores on the third place. 945but overall scores on the third place.
939 946
940C<Glib>'s memory usage is quite a bit bit higher, but it features a 947C<Glib>'s memory usage is quite a bit bit higher, but it features a
… …
948The C<Tk> adaptor works relatively well. The fact that it crashes with 955The C<Tk> adaptor works relatively well. The fact that it crashes with
949more than 2000 watchers is a big setback, however, as correctness takes 956more than 2000 watchers is a big setback, however, as correctness takes
950precedence over speed. Nevertheless, its performance is surprising, as the 957precedence over speed. Nevertheless, its performance is surprising, as the
951file descriptor is dup()ed for each watcher. This shows that the dup() 958file descriptor is dup()ed for each watcher. This shows that the dup()
952employed by some adaptors is not a big performance issue (it does incur a 959employed by some adaptors is not a big performance issue (it does incur a
953hidden memory cost inside the kernel, though). 960hidden memory cost inside the kernel, though, that is not reflected in the
961figures above).
954 962
955C<POE>, regardless of underlying event loop (wether using its pure perl 963C<POE>, regardless of underlying event loop (wether using its pure perl
956select-based backend or the Event module) shows abysmal performance and 964select-based backend or the Event module) shows abysmal performance and
957memory usage: Watchers use almost 30 times as much memory as EV watchers, 965memory usage: Watchers use almost 30 times as much memory as EV watchers,
958and 10 times as much memory as both Event or EV via AnyEvent. Watcher 966and 10 times as much memory as both Event or EV via AnyEvent. Watcher
959invocation is almost 700 times slower than with AnyEvent's pure perl 967invocation is almost 900 times slower than with AnyEvent's pure perl
960implementation. The design of the POE adaptor class in AnyEvent can not 968implementation. The design of the POE adaptor class in AnyEvent can not
961really account for this, as session creation overhead is small compared 969really account for this, as session creation overhead is small compared
962to execution of the state machine, which is coded pretty optimally within 970to execution of the state machine, which is coded pretty optimally within
963L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. 971L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
964 972

Diff Legend

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