summaryrefslogtreecommitdiff
path: root/ev.pod
diff options
context:
space:
mode:
authorroot <root>2007-12-23 03:57:55 +0000
committerroot <root>2007-12-23 03:57:55 +0000
commit9aa7e42975c9c89b27f67364aed821e9637f81ac (patch)
tree0c5d9f03db95dc8d8dd8bbf387bab6ad311f0399 /ev.pod
parent4a85f6e7f4dab185567125e88b7a333eba756df1 (diff)
*** empty log message ***
Diffstat (limited to 'ev.pod')
-rw-r--r--ev.pod20
1 files changed, 13 insertions, 7 deletions
diff --git a/ev.pod b/ev.pod
index 38c5015..2269dff 100644
--- a/ev.pod
+++ b/ev.pod
@@ -2634,16 +2634,17 @@ it is much faster and asymptotically approaches constant time.
This means that, when you have a watcher that triggers in one hour and
there are 100 watchers that would trigger before that then inserting will
-have to skip those 100 watchers.
+have to skip roughly seven (C<ld 100>) of these watchers.
-=item Changing timer/periodic watchers (by autorepeat, again): O(log skipped_other_timers)
+=item Changing timer/periodic watchers (by autorepeat or calling again): O(log skipped_other_timers)
-That means that for changing a timer costs less than removing/adding them
+That means that changing a timer costs less than removing/adding them
as only the relative motion in the event queue has to be paid for.
=item Starting io/check/prepare/idle/signal/child watchers: O(1)
These just add the watcher into an array or at the head of a list.
+
=item Stopping check/prepare/idle watchers: O(1)
=item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE))
@@ -2652,20 +2653,25 @@ These watchers are stored in lists then need to be walked to find the
correct watcher to remove. The lists are usually short (you don't usually
have many watchers waiting for the same fd or signal).
-=item Finding the next timer per loop iteration: O(1)
+=item Finding the next timer in each loop iteration: O(1)
+
+By virtue of using a binary heap, the next timer is always found at the
+beginning of the storage array.
=item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)
A change means an I/O watcher gets started or stopped, which requires
-libev to recalculate its status (and possibly tell the kernel).
+libev to recalculate its status (and possibly tell the kernel, depending
+on backend and wether C<ev_io_set> was used).
-=item Activating one watcher: O(1)
+=item Activating one watcher (putting it into the pending state): O(1)
=item Priority handling: O(number_of_priorities)
Priorities are implemented by allocating some space for each
priority. When doing priority-based operations, libev usually has to
-linearly search all the priorities.
+linearly search all the priorities, but starting/stopping and activating
+watchers becomes O(1) w.r.t. prioritiy handling.
=back