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.72 by root, Fri Apr 25 07:43:25 2008 UTC vs.
Revision 1.76 by root, Fri Apr 25 08:41:38 2008 UTC

… …
899I<destroy> is the time, in microseconds, that it takes to destroy a single 899I<destroy> is the time, in microseconds, that it takes to destroy a single
900watcher. 900watcher.
901 901
902=head2 Results 902=head2 Results
903 903
904 name watcher bytes create invoke destroy comment 904 name watchers bytes create invoke destroy comment
905 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 905 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 906 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 907 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 908 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 909 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 910 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 911 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 912 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 913 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 914 POE/Select 2000 6343 94.69 807.65 562.69 via POE::Loop::Select
915 915
916=head2 Discussion 916=head2 Discussion
917 917
918The benchmark does I<not> measure scalability of the event loop very 918The 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) 919well. For example, a select-based event loop (such as the pure perl one)
… …
921file descriptors grows high. In this benchmark, only a single filehandle 921file descriptors grows high. In this benchmark, only a single filehandle
922is used (although some of the AnyEvent adaptors dup() its file descriptor 922is used (although some of the AnyEvent adaptors dup() its file descriptor
923to worka round bugs). 923to worka round bugs).
924 924
925C<EV> is the sole leader regarding speed and memory use, which are both 925C<EV> is the sole leader regarding speed and memory use, which are both
926maximal/minimal, respectively. Even when going through AnyEvent, there is 926maximal/minimal, respectively. Even when going through AnyEvent, there are
927only one event loop that uses less memory (the C<Event> module natively), and 927only two event loops that use slightly less memory (the C<Event> module
928no faster event model, not event C<Event> natively. 928natively and the pure perl backend), and no faster event models, not even
929C<Event> natively.
929 930
930The pure perl implementation is hit in a few sweet spots (both the 931The 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 932zero timeout and the use of a single fd hit optimisations in the perl
932interpreter and the backend itself). Nevertheless tis shows that it 933interpreter and the backend itself). Nevertheless tis shows that it
933adds very little overhead in itself. Like any select-based backend its 934adds very little overhead in itself. Like any select-based backend its
934performance becomes really bad with lots of file descriptors, of course, 935performance becomes really bad with lots of file descriptors, of course,
935but this was not subjetc of this benchmark. 936but this was not subject of this benchmark.
936 937
937The C<Event> module has a relatively high setup and callback invocation cost, 938The C<Event> module has a relatively high setup and callback invocation cost,
938but overall scores on the third place. 939but overall scores on the third place.
939 940
940C<Glib>'s memory usage is quite a bit bit higher, features a faster 941C<Glib>'s memory usage is quite a bit bit higher, but it features a
941callback invocation and overall lands in the same class as C<Event>. 942faster callback invocation and overall ends up in the same class as
943C<Event>. However, Glib scales extremely badly, doubling the number of
944watchers increases the processing time by more than a factor of four,
945making it completely unusable when using larger numbers of watchers
946(note that only a single file descriptor was used in the benchmark, so
947inefficiencies of C<poll> do not account for this).
942 948
943The C<Tk> adaptor works relatively well, the fact that it crashes with 949The C<Tk> adaptor works relatively well. The fact that it crashes with
944more than 2000 watchers is a big setback, however, as correctness takes 950more than 2000 watchers is a big setback, however, as correctness takes
945precedence over speed. Nevertheless, its performance is surprising, as the 951precedence over speed. Nevertheless, its performance is surprising, as the
946file descriptor is dup()ed for each watcher. This shows that the dup() 952file descriptor is dup()ed for each watcher. This shows that the dup()
947employed by some adaptors is not a big performance issue (it does incur a 953employed by some adaptors is not a big performance issue (it does incur a
948hidden memory cost inside the kernel, though). 954hidden memory cost inside the kernel, though, that is not reflected in the
955figures above).
949 956
950C<POE>, regardless of underlying event loop (wether using its pure perl 957C<POE>, regardless of underlying event loop (wether using its pure perl
951select-based backend or the Event module) shows abysmal performance and 958select-based backend or the Event module) shows abysmal performance and
952memory usage: Watchers use almost 30 times as much memory as EV watchers, 959memory usage: Watchers use almost 30 times as much memory as EV watchers,
953and 10 times as much memory as both Event or EV via AnyEvent. Watcher 960and 10 times as much memory as both Event or EV via AnyEvent. Watcher
… …
962Using EV through AnyEvent is faster than any other event loop, but most 969Using EV through AnyEvent is faster than any other event loop, but most
963event loops have acceptable performance with or without AnyEvent. 970event loops have acceptable performance with or without AnyEvent.
964 971
965The overhead AnyEvent adds is usually much smaller than the overhead of 972The overhead AnyEvent adds is usually much smaller than the overhead of
966the actual event loop, only with extremely fast event loops such as the EV 973the actual event loop, only with extremely fast event loops such as the EV
967adds Anyevent significant overhead. 974adds AnyEvent significant overhead.
968 975
969And you should simply avoid POE like the plague if you want performance or 976And you should simply avoid POE like the plague if you want performance or
970reasonable memory usage. 977reasonable memory usage.
971 978
972 979

Diff Legend

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