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.85 by root, Fri Apr 25 13:51:32 2008 UTC vs.
Revision 1.87 by root, Fri Apr 25 14:07:20 2008 UTC

… …
964maximal/minimal, respectively. Even when going through AnyEvent, it uses 964maximal/minimal, respectively. Even when going through AnyEvent, it uses
965far less memory than any other event loop and is still faster than Event 965far less memory than any other event loop and is still faster than Event
966natively. 966natively.
967 967
968The pure perl implementation is hit in a few sweet spots (both the 968The pure perl implementation is hit in a few sweet spots (both the
969zero timeout and the use of a single fd hit optimisations in the perl 969constant timeout and the use of a single fd hit optimisations in the perl
970interpreter and the backend itself, and all watchers become ready at the 970interpreter and the backend itself). Nevertheless this shows that it
971same time). Nevertheless this shows that it adds very little overhead in 971adds very little overhead in itself. Like any select-based backend its
972itself. Like any select-based backend its performance becomes really bad 972performance becomes really bad with lots of file descriptors (and few of
973with lots of file descriptors (and few of them active), of course, but 973them active), of course, but this was not subject of this benchmark.
974this was not subject of this benchmark.
975 974
976The C<Event> module has a relatively high setup and callback invocation cost, 975The C<Event> module has a relatively high setup and callback invocation cost,
977but overall scores on the third place. 976but overall scores on the third place.
978 977
979C<Glib>'s memory usage is quite a bit bit higher, but it features a 978C<Glib>'s memory usage is quite a bit bit higher, but it features a
… …
987The C<Tk> adaptor works relatively well. The fact that it crashes with 986The C<Tk> adaptor works relatively well. The fact that it crashes with
988more than 2000 watchers is a big setback, however, as correctness takes 987more than 2000 watchers is a big setback, however, as correctness takes
989precedence over speed. Nevertheless, its performance is surprising, as the 988precedence over speed. Nevertheless, its performance is surprising, as the
990file descriptor is dup()ed for each watcher. This shows that the dup() 989file descriptor is dup()ed for each watcher. This shows that the dup()
991employed by some adaptors is not a big performance issue (it does incur a 990employed by some adaptors is not a big performance issue (it does incur a
992hidden memory cost inside the kernel, though, that is not reflected in the 991hidden memory cost inside the kernel which is not reflected in the figures
993figures above). 992above).
994 993
995C<POE>, regardless of underlying event loop (wether using its pure perl 994C<POE>, regardless of underlying event loop (whether using its pure
996select-based backend or the Event module) shows abysmal performance and 995perl select-based backend or the Event module, the POE-EV backend
996couldn't be tested because it wasn't working) shows abysmal performance
997memory usage: Watchers use almost 30 times as much memory as EV watchers, 997and memory usage: Watchers use almost 30 times as much memory as
998and 10 times as much memory as both Event or EV via AnyEvent. Watcher 998EV watchers, and 10 times as much memory as Event (the high memory
999requirements are caused by requiring a session for each watcher). Watcher
999invocation is almost 900 times slower than with AnyEvent's pure perl 1000invocation speed is almost 900 times slower than with AnyEvent's pure perl
1000implementation. The design of the POE adaptor class in AnyEvent can not 1001implementation. The design of the POE adaptor class in AnyEvent can not
1001really account for this, as session creation overhead is small compared 1002really account for this, as session creation overhead is small compared
1002to execution of the state machine, which is coded pretty optimally within 1003to execution of the state machine, which is coded pretty optimally within
1003L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. 1004L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
1004 1005
1005=head2 Summary 1006=head2 Summary
1006 1007
1008=over 4
1009
1007Using EV through AnyEvent is faster than any other event loop, but most 1010=item * Using EV through AnyEvent is faster than any other event loop, but most
1008event loops have acceptable performance with or without AnyEvent. 1011event loops have acceptable performance with or without AnyEvent.
1009 1012
1010The overhead AnyEvent adds is usually much smaller than the overhead of 1013=item * The overhead AnyEvent adds is usually much smaller than the overhead of
1011the actual event loop, only with extremely fast event loops such as the EV 1014the actual event loop, only with extremely fast event loops such as the EV
1012adds AnyEvent significant overhead. 1015adds AnyEvent significant overhead.
1013 1016
1014And you should simply avoid POE like the plague if you want performance or 1017=item * And you should simply avoid POE like the plague if you want performance or
1015reasonable memory usage. 1018reasonable memory usage.
1019
1020=back
1016 1021
1017 1022
1018=head1 FORK 1023=head1 FORK
1019 1024
1020Most event libraries are not fork-safe. The ones who are usually are 1025Most event libraries are not fork-safe. The ones who are usually are

Diff Legend

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