--- libev/ev.pod 2008/05/06 23:42:16 1.151 +++ libev/ev.pod 2008/05/09 15:52:13 1.153 @@ -2982,8 +2982,9 @@ =item EV_MINIMAL If you need to shave off some kilobytes of code at the expense of some -speed, define this symbol to C<1>. Currently only used for gcc to override -some inlining decisions, saves roughly 30% codesize of amd64. +speed, define this symbol to C<1>. Currently this is used to override some +inlining decisions, saves roughly 30% codesize of amd64. It also selects a +much smaller 2-heap for timer management over the default 4-heap. =item EV_PID_HASHSIZE @@ -3000,6 +3001,28 @@ watchers you might want to increase this value (I be a power of two). +=item EV_USE_4HEAP + +Heaps are not very cache-efficient. To improve the cache-efficiency of the +timer and periodics heap, libev uses a 4-heap when this symbol is defined +to C<1>. The 4-heap uses more complicated (longer) code but has a +noticable after performance with many (thousands) of watchers. + +The default is C<1> unless C is set in which case it is C<0> +(disabled). + +=item EV_HEAP_CACHE_AT + +Heaps are not very cache-efficient. To improve the cache-efficiency of the +timer and periodics heap, libev can cache the timestamp (I) within +the heap structure (selected by defining C to C<1>), +which uses 8-12 bytes more per watcher and a few hundred bytes more code, +but avoids random read accesses on heap changes. This noticably improves +performance noticably with with many (hundreds) of watchers. + +The default is C<1> unless C is set in which case it is C<0> +(disabled). + =item EV_COMMON By default, all watchers have a C member. By redefining @@ -3178,8 +3201,8 @@ =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. +By virtue of using a binary or 4-heap, the next timer is always found at a +fixed position in the storage array. =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)