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.217 by root, Tue Jun 23 23:37:32 2009 UTC vs.
Revision 1.218 by root, Wed Jun 24 10:03:42 2009 UTC

… …
1366=item C<PERL_ANYEVENT_STRICT> 1366=item C<PERL_ANYEVENT_STRICT>
1367 1367
1368AnyEvent does not do much argument checking by default, as thorough 1368AnyEvent does not do much argument checking by default, as thorough
1369argument checking is very costly. Setting this variable to a true value 1369argument checking is very costly. Setting this variable to a true value
1370will cause AnyEvent to load C<AnyEvent::Strict> and then to thoroughly 1370will cause AnyEvent to load C<AnyEvent::Strict> and then to thoroughly
1371check the arguments passed to most method calls. If it finds any problems 1371check the arguments passed to most method calls. If it finds any problems,
1372it will croak. 1372it will croak.
1373 1373
1374In other words, enables "strict" mode. 1374In other words, enables "strict" mode.
1375 1375
1376Unlike C<use strict>, it is definitely recommended ot keep it off in 1376Unlike C<use strict>, it is definitely recommended to keep it off in
1377production. Keeping C<PERL_ANYEVENT_STRICT=1> in your environment while 1377production. Keeping C<PERL_ANYEVENT_STRICT=1> in your environment while
1378developing programs can be very useful, however. 1378developing programs can be very useful, however.
1379 1379
1380=item C<PERL_ANYEVENT_MODEL> 1380=item C<PERL_ANYEVENT_MODEL>
1381 1381
… …
1900 1900
1901Recently I was told about the benchmark in the IO::Lambda manpage, which 1901Recently I was told about the benchmark in the IO::Lambda manpage, which
1902could be misinterpreted to make AnyEvent look bad. In fact, the benchmark 1902could be misinterpreted to make AnyEvent look bad. In fact, the benchmark
1903simply compares IO::Lambda with POE, and IO::Lambda looks better (which 1903simply compares IO::Lambda with POE, and IO::Lambda looks better (which
1904shouldn't come as a surprise to anybody). As such, the benchmark is 1904shouldn't come as a surprise to anybody). As such, the benchmark is
1905fine, and shows that the AnyEvent backend from IO::Lambda isn't very 1905fine, and mostly shows that the AnyEvent backend from IO::Lambda isn't
1906optimal. But how would AnyEvent compare when used without the extra 1906very optimal. But how would AnyEvent compare when used without the extra
1907baggage? To explore this, I wrote the equivalent benchmark for AnyEvent. 1907baggage? To explore this, I wrote the equivalent benchmark for AnyEvent.
1908 1908
1909The benchmark itself creates an echo-server, and then, for 500 times, 1909The benchmark itself creates an echo-server, and then, for 500 times,
1910connects to the echo server, sends a line, waits for the reply, and then 1910connects to the echo server, sends a line, waits for the reply, and then
1911creates the next connection. This is a rather bad benchmark, as it doesn't 1911creates the next connection. This is a rather bad benchmark, as it doesn't
1912test the efficiency of the framework, but it is a benchmark nevertheless. 1912test the efficiency of the framework or much non-blocking I/O, but it is a
1913benchmark nevertheless.
1913 1914
1914 name runtime 1915 name runtime
1915 Lambda/select 0.330 sec 1916 Lambda/select 0.330 sec
1916 + optimized 0.122 sec 1917 + optimized 0.122 sec
1917 Lambda/AnyEvent 0.327 sec 1918 Lambda/AnyEvent 0.327 sec
… …
1923 1924
1924 AnyEvent/select/nb 0.085 sec 1925 AnyEvent/select/nb 0.085 sec
1925 AnyEvent/EV/nb 0.068 sec 1926 AnyEvent/EV/nb 0.068 sec
1926 +state machine 0.134 sec 1927 +state machine 0.134 sec
1927 1928
1928The benchmark is also a bit unfair (my fault) - the IO::Lambda 1929The benchmark is also a bit unfair (my fault): the IO::Lambda/POE
1929benchmarks actually make blocking connects and use 100% blocking I/O, 1930benchmarks actually make blocking connects and use 100% blocking I/O,
1930defeating the purpose of an event-based solution. All of the newly 1931defeating the purpose of an event-based solution. All of the newly
1931written AnyEvent benchmarks use 100% non-blocking connects (using 1932written AnyEvent benchmarks use 100% non-blocking connects (using
1932AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS 1933AnyEvent::Socket::tcp_connect and the asynchronous pure perl DNS
1933resolver), so AnyEvent is at a disadvantage here as non-blocking connects 1934resolver), so AnyEvent is at a disadvantage here, as non-blocking connects
1934generally require a lot more bookkeeping and event handling than blocking 1935generally require a lot more bookkeeping and event handling than blocking
1935connects (which involve a single syscall only). 1936connects (which involve a single syscall only).
1936 1937
1937The last AnyEvent benchmark additionally uses L<AnyEvent::Handle>, which 1938The last AnyEvent benchmark additionally uses L<AnyEvent::Handle>, which
1938offers similar expressive power as POE and IO::Lambda (using conventional 1939offers similar expressive power as POE and IO::Lambda, using conventional
1939Perl syntax), which means both the echo server and the client are 100% 1940Perl syntax. This means that both the echo server and the client are 100%
1940non-blocking w.r.t. I/O, further placing it at a disadvantage. 1941non-blocking, further placing it at a disadvantage.
1941 1942
1942As you can see, AnyEvent + EV even beats the hand-optimised "raw sockets 1943As you can see, the AnyEvent + EV combination even beats the
1943benchmark", while AnyEvent + its pure perl backend easily beats 1944hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1944IO::Lambda and POE. 1945backend easily beats IO::Lambda and POE.
1945 1946
1946And even the 100% non-blocking version written using the high-level (and 1947And even the 100% non-blocking version written using the high-level (and
1947slow :) L<AnyEvent::Handle> abstraction beats both POE and IO::Lambda, 1948slow :) L<AnyEvent::Handle> abstraction beats both POE and IO::Lambda by a
1948even thought it does all of DNS, tcp-connect and socket I/O in a 1949large margin, even though it does all of DNS, tcp-connect and socket I/O
1949non-blocking way. 1950in a non-blocking way.
1950 1951
1951The two AnyEvent benchmarks can be found as F<eg/ae0.pl> and F<eg/ae2.pl> 1952The two AnyEvent benchmarks programs can be found as F<eg/ae0.pl> and
1952in the AnyEvent distribution, the remaining benchmarks are part of the 1953F<eg/ae2.pl> in the AnyEvent distribution, the remaining benchmarks are
1953IO::lambda distribution and were used without any changes. 1954part of the IO::lambda distribution and were used without any changes.
1954 1955
1955 1956
1956=head1 SIGNALS 1957=head1 SIGNALS
1957 1958
1958AnyEvent currently installs handlers for these signals: 1959AnyEvent currently installs handlers for these signals:
… …
2018Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can 2019Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
2019be used to probe what backend is used and gain other information (which is 2020be used to probe what backend is used and gain other information (which is
2020probably even less useful to an attacker than PERL_ANYEVENT_MODEL), and 2021probably even less useful to an attacker than PERL_ANYEVENT_MODEL), and
2021$ENV{PERL_ANYEVENT_STRICT}. 2022$ENV{PERL_ANYEVENT_STRICT}.
2022 2023
2024Note that AnyEvent will remove I<all> environment variables starting with
2025C<PERL_ANYEVENT_> from C<%ENV> when it is loaded while taint mode is
2026enabled.
2027
2023 2028
2024=head1 BUGS 2029=head1 BUGS
2025 2030
2026Perl 5.8 has numerous memleaks that sometimes hit this module and are hard 2031Perl 5.8 has numerous memleaks that sometimes hit this module and are hard
2027to work around. If you suffer from memleaks, first upgrade to Perl 5.10 2032to work around. If you suffer from memleaks, first upgrade to Perl 5.10

Diff Legend

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