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

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.70 by root, Fri Apr 25 07:25:44 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.70 by root, Fri Apr 25 07:25:44 2008 UTC