[ViewVC] Diff of: cvs/AnyEvent/lib/AnyEvent.pm

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.62 by root, Fri Apr 25 02:03:18 2008 UTC vs.
Revision 1.72 by root, Fri Apr 25 07:43:25 2008 UTC

…		…
434	no warnings;	434	no warnings;
435	use strict;	435	use strict;
436		436
437	use Carp;	437	use Carp;
438		438
439	our $VERSION = '3.2';	439	our $VERSION = '3.3';
440	our $MODEL;	440	our $MODEL;
441		441
442	our $AUTOLOAD;	442	our $AUTOLOAD;
443	our @ISA;	443	our @ISA;
444		444
…		…
860	$quit->broadcast;	860	$quit->broadcast;
861	});	861	});
862		862
863	$quit->wait;	863	$quit->wait;
864		864
		865
		866	=head1 BENCHMARK
		867
		868	To give you an idea of the performance and overheads that AnyEvent adds
		869	over the event loops themselves (and to give you an impression of the
		870	speed of various event loops), here is a benchmark of various supported
		871	event models natively and with anyevent. The benchmark creates a lot of
		872	timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to
		873	become writable, which it is), lets them fire exactly once and destroys
		874	them again.
		875
		876	=head2 Explanation of the columns
		877
		878	I<watcher> is the number of event watchers created/destroyed. Since
		879	different event models feature vastly different performances, each event
		880	loop was given a number of watchers so that overall runtime is acceptable
		881	and similar between tested event loop (and keep them from crashing): Glib
		882	would probably take thousands of years if asked to process the same number
		883	of watchers as EV in this benchmark.
		884
		885	I<bytes> is the number of bytes (as measured by the resident set size,
		886	RSS) consumed by each watcher. This method of measuring captures both C
		887	and Perl-based overheads.
		888
		889	I<create> is the time, in microseconds (millionths of seconds), that it
		890	takes to create a single watcher. The callback is a closure shared between
		891	all watchers, to avoid adding memory overhead. That means closure creation
		892	and memory usage is not included in the figures.
		893
		894	I<invoke> is the time, in microseconds, used to invoke a simple
		895	callback. The callback simply counts down a Perl variable and after it was
		896	invoked "watcher" times, it would C<< ->broadcast >> a condvar once to
		897	signal the end of this phase.
		898
		899	I<destroy> is the time, in microseconds, that it takes to destroy a single
		900	watcher.
		901
		902	=head2 Results
		903
		904	name watcher bytes create invoke destroy comment
		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
		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
		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
		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
		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
		915
		916	=head2 Discussion
		917
		918	The benchmark does I<not> measure scalability of the event loop very
		919	well. For example, a select-based event loop (such as the pure perl one)
		920	can never compete with an event loop that uses epoll when the number of
		921	file descriptors grows high. In this benchmark, only a single filehandle
		922	is used (although some of the AnyEvent adaptors dup() its file descriptor
		923	to worka round bugs).
		924
		925	C<EV> is the sole leader regarding speed and memory use, which are both
		926	maximal/minimal, respectively. Even when going through AnyEvent, there is
		927	only one event loop that uses less memory (the C<Event> module natively), and
		928	no faster event model, not event C<Event> natively.
		929
		930	The pure perl implementation is hit in a few sweet spots (both the
		931	zero timeout and the use of a single fd hit optimisations in the perl
		932	interpreter and the backend itself). Nevertheless tis shows that it
		933	adds very little overhead in itself. Like any select-based backend its
		934	performance becomes really bad with lots of file descriptors, of course,
		935	but this was not subjetc of this benchmark.
		936
		937	The C<Event> module has a relatively high setup and callback invocation cost,
		938	but overall scores on the third place.
		939
		940	C<Glib>'s memory usage is quite a bit bit higher, features a faster
		941	callback invocation and overall lands in the same class as C<Event>.
		942
		943	The C<Tk> adaptor works relatively well, the fact that it crashes with
		944	more than 2000 watchers is a big setback, however, as correctness takes
		945	precedence over speed. Nevertheless, its performance is surprising, as the
		946	file descriptor is dup()ed for each watcher. This shows that the dup()
		947	employed by some adaptors is not a big performance issue (it does incur a
		948	hidden memory cost inside the kernel, though).
		949
		950	C<POE>, regardless of underlying event loop (wether using its pure perl
		951	select-based backend or the Event module) shows abysmal performance and
		952	memory usage: Watchers use almost 30 times as much memory as EV watchers,
		953	and 10 times as much memory as both Event or EV via AnyEvent. Watcher
		954	invocation is almost 700 times slower than with AnyEvent's pure perl
		955	implementation. The design of the POE adaptor class in AnyEvent can not
		956	really account for this, as session creation overhead is small compared
		957	to execution of the state machine, which is coded pretty optimally within
		958	L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
		959
		960	=head2 Summary
		961
		962	Using EV through AnyEvent is faster than any other event loop, but most
		963	event loops have acceptable performance with or without AnyEvent.
		964
		965	The overhead AnyEvent adds is usually much smaller than the overhead of
		966	the actual event loop, only with extremely fast event loops such as the EV
		967	adds Anyevent significant overhead.
		968
		969	And you should simply avoid POE like the plague if you want performance or
		970	reasonable memory usage.
		971
		972
865	=head1 FORK	973	=head1 FORK
866		974
867	Most event libraries are not fork-safe. The ones who are usually are	975	Most event libraries are not fork-safe. The ones who are usually are
868	because they are so inefficient. Only L<EV> is fully fork-aware.	976	because they are so inefficient. Only L<EV> is fully fork-aware.
869		977
870	If you have to fork, you must either do so I<before> creating your first	978	If you have to fork, you must either do so I<before> creating your first
871	watcher OR you must not use AnyEvent at all in the child.	979	watcher OR you must not use AnyEvent at all in the child.
		980
872		981
873	=head1 SECURITY CONSIDERATIONS	982	=head1 SECURITY CONSIDERATIONS
874		983
875	AnyEvent can be forced to load any event model via	984	AnyEvent can be forced to load any event model via
876	$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to	985	$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to
…		…
884		993
885	BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }	994	BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
886		995
887	use AnyEvent;	996	use AnyEvent;
888		997
		998
889	=head1 SEE ALSO	999	=head1 SEE ALSO
890		1000
891	Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>,	1001	Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>,
892	L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>,	1002	L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>,
893	L<Event::Lib>, L<Qt>, L<POE>.	1003	L<Event::Lib>, L<Qt>, L<POE>.
…		…
897	L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,	1007	L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,
898	L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.	1008	L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.
899		1009
900	Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.	1010	Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.
901		1011
		1012
902	=head1 AUTHOR	1013	=head1 AUTHOR
903		1014
904	Marc Lehmann <schmorp@schmorp.de>	1015	Marc Lehmann <schmorp@schmorp.de>
905	http://home.schmorp.de/	1016	http://home.schmorp.de/
906		1017

Diff Legend

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

Comparing AnyEvent/lib/AnyEvent.pm (file contents): Revision 1.62 by root, Fri Apr 25 02:03:18 2008 UTC vs. Revision 1.72 by root, Fri Apr 25 07:43:25 2008 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.62 by root, Fri Apr 25 02:03:18 2008 UTC vs.
Revision 1.72 by root, Fri Apr 25 07:43:25 2008 UTC