… | |
… | |
811 | |
811 | |
812 | By setting a higher I<io collect interval> you allow libev to spend more |
812 | By setting a higher I<io collect interval> you allow libev to spend more |
813 | time collecting I/O events, so you can handle more events per iteration, |
813 | time collecting I/O events, so you can handle more events per iteration, |
814 | at the cost of increasing latency. Timeouts (both C<ev_periodic> and |
814 | at the cost of increasing latency. Timeouts (both C<ev_periodic> and |
815 | C<ev_timer>) will be not affected. Setting this to a non-null value will |
815 | C<ev_timer>) will be not affected. Setting this to a non-null value will |
816 | introduce an additional C<ev_sleep ()> call into most loop iterations. |
816 | introduce an additional C<ev_sleep ()> call into most loop iterations. The |
|
|
817 | sleep time ensures that libev will not poll for I/O events more often then |
|
|
818 | once per this interval, on average. |
817 | |
819 | |
818 | Likewise, by setting a higher I<timeout collect interval> you allow libev |
820 | Likewise, by setting a higher I<timeout collect interval> you allow libev |
819 | to spend more time collecting timeouts, at the expense of increased |
821 | to spend more time collecting timeouts, at the expense of increased |
820 | latency/jitter/inexactness (the watcher callback will be called |
822 | latency/jitter/inexactness (the watcher callback will be called |
821 | later). C<ev_io> watchers will not be affected. Setting this to a non-null |
823 | later). C<ev_io> watchers will not be affected. Setting this to a non-null |
… | |
… | |
823 | |
825 | |
824 | Many (busy) programs can usually benefit by setting the I/O collect |
826 | Many (busy) programs can usually benefit by setting the I/O collect |
825 | interval to a value near C<0.1> or so, which is often enough for |
827 | interval to a value near C<0.1> or so, which is often enough for |
826 | interactive servers (of course not for games), likewise for timeouts. It |
828 | interactive servers (of course not for games), likewise for timeouts. It |
827 | usually doesn't make much sense to set it to a lower value than C<0.01>, |
829 | usually doesn't make much sense to set it to a lower value than C<0.01>, |
828 | as this approaches the timing granularity of most systems. |
830 | as this approaches the timing granularity of most systems. Note that if |
|
|
831 | you do transactions with the outside world and you can't increase the |
|
|
832 | parallelity, then this setting will limit your transaction rate (if you |
|
|
833 | need to poll once per transaction and the I/O collect interval is 0.01, |
|
|
834 | then you can't do more than 100 transations per second). |
829 | |
835 | |
830 | Setting the I<timeout collect interval> can improve the opportunity for |
836 | Setting the I<timeout collect interval> can improve the opportunity for |
831 | saving power, as the program will "bundle" timer callback invocations that |
837 | saving power, as the program will "bundle" timer callback invocations that |
832 | are "near" in time together, by delaying some, thus reducing the number of |
838 | are "near" in time together, by delaying some, thus reducing the number of |
833 | times the process sleeps and wakes up again. Another useful technique to |
839 | times the process sleeps and wakes up again. Another useful technique to |
834 | reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure |
840 | reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure |
835 | they fire on, say, one-second boundaries only. |
841 | they fire on, say, one-second boundaries only. |
|
|
842 | |
|
|
843 | Example: we only need 0.1s timeout granularity, and we wish not to poll |
|
|
844 | more often than 100 times per second: |
|
|
845 | |
|
|
846 | ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1); |
|
|
847 | ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01); |
836 | |
848 | |
837 | =item ev_loop_verify (loop) |
849 | =item ev_loop_verify (loop) |
838 | |
850 | |
839 | This function only does something when C<EV_VERIFY> support has been |
851 | This function only does something when C<EV_VERIFY> support has been |
840 | compiled in, which is the default for non-minimal builds. It tries to go |
852 | compiled in, which is the default for non-minimal builds. It tries to go |