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.86 by root, Fri Apr 25 14:01:48 2008 UTC vs.
Revision 1.87 by root, Fri Apr 25 14:07:20 2008 UTC

… …
986The 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
987more than 2000 watchers is a big setback, however, as correctness takes 987more than 2000 watchers is a big setback, however, as correctness takes
988precedence over speed. Nevertheless, its performance is surprising, as the 988precedence over speed. Nevertheless, its performance is surprising, as the
989file 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()
990employed 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
991hidden 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
992figures above). 992above).
993 993
994C<POE>, regardless of underlying event loop (whether using its pure perl 994C<POE>, regardless of underlying event loop (whether using its pure
995select-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
996memory usage: Watchers use almost 30 times as much memory as EV watchers, 997and memory usage: Watchers use almost 30 times as much memory as
997and 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
998invocation is almost 900 times slower than with AnyEvent's pure perl 1000invocation speed is almost 900 times slower than with AnyEvent's pure perl
999implementation. The design of the POE adaptor class in AnyEvent can not 1001implementation. The design of the POE adaptor class in AnyEvent can not
1000really account for this, as session creation overhead is small compared 1002really account for this, as session creation overhead is small compared
1001to execution of the state machine, which is coded pretty optimally within 1003to execution of the state machine, which is coded pretty optimally within
1002L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. 1004L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
1003 1005
1004=head2 Summary 1006=head2 Summary
1005 1007
1008=over 4
1009
1006Using 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
1007event loops have acceptable performance with or without AnyEvent. 1011event loops have acceptable performance with or without AnyEvent.
1008 1012
1009The 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
1010the 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
1011adds AnyEvent significant overhead. 1015adds AnyEvent significant overhead.
1012 1016
1013And 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
1014reasonable memory usage. 1018reasonable memory usage.
1019
1020=back
1015 1021
1016 1022
1017=head1 FORK 1023=head1 FORK
1018 1024
1019Most 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