diff options
author | root <root> | 2007-12-23 03:57:55 +0000 |
---|---|---|
committer | root <root> | 2007-12-23 03:57:55 +0000 |
commit | 9aa7e42975c9c89b27f67364aed821e9637f81ac (patch) | |
tree | 0c5d9f03db95dc8d8dd8bbf387bab6ad311f0399 /ev.pod | |
parent | 4a85f6e7f4dab185567125e88b7a333eba756df1 (diff) |
*** empty log message ***
Diffstat (limited to 'ev.pod')
-rw-r--r-- | ev.pod | 20 |
1 files changed, 13 insertions, 7 deletions
@@ -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 |