From 9aa7e42975c9c89b27f67364aed821e9637f81ac Mon Sep 17 00:00:00 2001 From: root Date: Sun, 23 Dec 2007 03:57:55 +0000 Subject: *** empty log message *** --- ev.pod | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) (limited to 'ev.pod') 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) 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 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 -- cgit v1.2.3