|
|
|
@ -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
|
|
|
|
|
|
|
|
|
|