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

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.63 by root, Fri Apr 25 02:03:38 2008 UTC vs.
Revision 1.68 by root, Fri Apr 25 07:14:33 2008 UTC

…		…
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 directly, here is a benchmark of various supported
		870	event models natively and with anyevent. The benchmark creates a lot of
		871	timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to
		872	become writable, which it is), lets them fire exactly once and destroys
		873	them again.
		874
		875	=head2 Explanation of the fields
		876
		877	I<watcher> is the number of event watchers created/destroyed. Since
		878	different event models feature vastly different performances, each event
		879	loop was given a number of watchers so that overall runtime is acceptable
		880	and similar between tested event loop (and keep them from crashing): Glib
		881	would probably take thousands of years if asked to process the same number
		882	of watchers as EV in this benchmark.
		883
		884	I<bytes> is the number of bytes (as measured by the resident set size,
		885	RSS) consumed by each watcher. This method of measuring captures both C
		886	and Perl-based overheads.
		887
		888	I<create> is the time, in microseconds (millionths of seconds), that it
		889	takes to create a single watcher. The callback is a closure shared between
		890	all watchers, to avoid adding memory overhead. That means closure creation
		891	and memory usage is not included in the figures.
		892
		893	I<invoke> is the time, in microseconds, used to invoke a simple
		894	callback. The callback simply counts down a Perl variable and after it was
		895	invoked "watcher" times, it would C<< ->broadcast >> a condvar once.
		896
		897	I<destroy> is the time, in microseconds, that it takes destroy a single
		898	watcher.
		899
		900	=head2 Results
		901
		902	name watcher bytes create invoke destroy comment
		903	EV/EV 400000 244 0.56 0.46 0.31 EV native interface
		904	EV/Any 100000 610 3.52 0.91 0.75
		905	CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal
		906	Perl/Any 10000 654 4.64 1.22 0.77 pure perl implementation
		907	Event/Event 10000 523 28.05 21.38 5.22 Event native interface
		908	Event/Any 10000 943 34.43 20.48 1.39
		909	Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour
		910	Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers
		911	POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select
		912	POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event
		913
		914	=head2 Discussion
		915
		916	The benchmark does I<not> measure scalability of the event loop very
		917	well. For example, a select-based event loop (such as the pure perl one)
		918	can never compete with an event loop that uses epoll when the number of
		919	file descriptors grows high. In this benchmark, only a single filehandle
		920	is used (although some of the AnyEvent adaptors dup() its file descriptor
		921	to worka round bugs).
		922
		923	C<EV> is the sole leader regarding speed and memory use, which are both
		924	maximal/minimal, respectively. Even when going through AnyEvent, there is
		925	only one event loop that uses less memory (the C<Event> module natively), and
		926	no faster event model, not event C<Event> natively.
		927
		928	The pure perl implementation is hit in a few sweet spots (both the
		929	zero timeout and the use of a single fd hit optimisations in the perl
		930	interpreter and the backend itself). Nevertheless tis shows that it
		931	adds very little overhead in itself. Like any select-based backend its
		932	performance becomes really bad with lots of file descriptors, of course,
		933	but this was not subjetc of this benchmark.
		934
		935	The C<Event> module has a relatively high setup and callback invocation cost,
		936	but overall scores on the third place.
		937
		938	C<Glib>'s memory usage is quite a bit bit higher, features a faster
		939	callback invocation and overall lands in the same class as C<Event>.
		940
		941	The C<Tk> adaptor works relatively well, the fact that it crashes with
		942	more than 2000 watchers is a big setback, however, as correctness takes
		943	precedence over speed. Nevertheless, its performance is surprising, as the
		944	file descriptor is dup()ed for each watcher. This shows that the dup()
		945	employed by some adaptors is not a big performance issue (it does incur a
		946	hidden memory cost inside the kernel, though).
		947
		948	C<POE>, regardless of backend (wether using its pure perl select-based
		949	backend or the Event backend) shows abysmal performance and memory
		950	usage: Watchers use almost 30 times as much memory as EV watchers, and 10
		951	times as much memory as both Event or EV via AnyEvent. Watcher invocation
		952	is almost 700 times slower as with AnyEvent's pure perl implementation.
		953
		954	Summary: using EV through AnyEvent is faster than any other event
		955	loop. The overhead AnyEvent adds can be very small, and you should avoid
		956	POE like the plague if you want performance or reasonable memory usage.
		957
		958
865	=head1 FORK	959	=head1 FORK
866		960
867	Most event libraries are not fork-safe. The ones who are usually are	961	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.	962	because they are so inefficient. Only L<EV> is fully fork-aware.
869		963
870	If you have to fork, you must either do so I<before> creating your first	964	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.	965	watcher OR you must not use AnyEvent at all in the child.
		966
872		967
873	=head1 SECURITY CONSIDERATIONS	968	=head1 SECURITY CONSIDERATIONS
874		969
875	AnyEvent can be forced to load any event model via	970	AnyEvent can be forced to load any event model via
876	$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to	971	$ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to
…		…
884		979
885	BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }	980	BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
886		981
887	use AnyEvent;	982	use AnyEvent;
888		983
		984
889	=head1 SEE ALSO	985	=head1 SEE ALSO
890		986
891	Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>,	987	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>,	988	L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>,
893	L<Event::Lib>, L<Qt>, L<POE>.	989	L<Event::Lib>, L<Qt>, L<POE>.
…		…
897	L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,	993	L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>,
898	L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.	994	L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>.
899		995
900	Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.	996	Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>.
901		997
		998
902	=head1 AUTHOR	999	=head1 AUTHOR
903		1000
904	Marc Lehmann <schmorp@schmorp.de>	1001	Marc Lehmann <schmorp@schmorp.de>
905	http://home.schmorp.de/	1002	http://home.schmorp.de/
906		1003

Diff Legend

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

Comparing AnyEvent/lib/AnyEvent.pm (file contents): Revision 1.63 by root, Fri Apr 25 02:03:38 2008 UTC vs. Revision 1.68 by root, Fri Apr 25 07:14:33 2008 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.63 by root, Fri Apr 25 02:03:38 2008 UTC vs.
Revision 1.68 by root, Fri Apr 25 07:14:33 2008 UTC