[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.75 by root, Fri Apr 25 07:49:39 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 watchers 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, but it features a
		941	faster callback invocation and overall ends up in the same class as
		942	C<Event>. However, Glib scales extremely badly, doubling the number of
		943	watchers increases the processing time by more than a factor of four,
		944	making it completely unusable when using larger numbers of watchers
		945	(note that only a single file descriptor was used in the benchmark, so
		946	inefficiencies of C<poll> do not account for this).
		947
		948	The C<Tk> adaptor works relatively well. The fact that it crashes with
		949	more than 2000 watchers is a big setback, however, as correctness takes
		950	precedence over speed. Nevertheless, its performance is surprising, as the
		951	file descriptor is dup()ed for each watcher. This shows that the dup()
		952	employed by some adaptors is not a big performance issue (it does incur a
		953	hidden memory cost inside the kernel, though, that is not reflected in the
		954	figures above).
		955
		956	C<POE>, regardless of underlying event loop (wether using its pure perl
		957	select-based backend or the Event module) shows abysmal performance and
		958	memory usage: Watchers use almost 30 times as much memory as EV watchers,
		959	and 10 times as much memory as both Event or EV via AnyEvent. Watcher
		960	invocation is almost 700 times slower than with AnyEvent's pure perl
		961	implementation. The design of the POE adaptor class in AnyEvent can not
		962	really account for this, as session creation overhead is small compared
		963	to execution of the state machine, which is coded pretty optimally within
		964	L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
		965
		966	=head2 Summary
		967
		968	Using EV through AnyEvent is faster than any other event loop, but most
		969	event loops have acceptable performance with or without AnyEvent.
		970
		971	The overhead AnyEvent adds is usually much smaller than the overhead of
		972	the actual event loop, only with extremely fast event loops such as the EV
		973	adds AnyEvent significant overhead.
		974
		975	And you should simply avoid POE like the plague if you want performance or
		976	reasonable memory usage.
		977
		978
865	=head1 FORK	979	=head1 FORK
866		980
867	Most event libraries are not fork-safe. The ones who are usually are	981	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.	982	because they are so inefficient. Only L<EV> is fully fork-aware.
869		983
870	If you have to fork, you must either do so I<before> creating your first	984	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.	985	watcher OR you must not use AnyEvent at all in the child.
		986
872		987
873	=head1 SECURITY CONSIDERATIONS	988	=head1 SECURITY CONSIDERATIONS
874		989
875	AnyEvent can be forced to load any event model via	990	AnyEvent can be forced to load any event model via
876	$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to	991	$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to
…		…
884		999
885	BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }	1000	BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
886		1001
887	use AnyEvent;	1002	use AnyEvent;
888		1003
		1004
889	=head1 SEE ALSO	1005	=head1 SEE ALSO
890		1006
891	Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>,	1007	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>,	1008	L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>,
893	L<Event::Lib>, L<Qt>, L<POE>.	1009	L<Event::Lib>, L<Qt>, L<POE>.
…		…
897	L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,	1013	L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,
898	L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.	1014	L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.
899		1015
900	Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.	1016	Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.
901		1017
		1018
902	=head1 AUTHOR	1019	=head1 AUTHOR
903		1020
904	Marc Lehmann <schmorp@schmorp.de>	1021	Marc Lehmann <schmorp@schmorp.de>
905	http://home.schmorp.de/	1022	http://home.schmorp.de/
906		1023

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.75 by root, Fri Apr 25 07:49:39 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.75 by root, Fri Apr 25 07:49:39 2008 UTC