> > So, the new result ...
> > Maybe my test script is not optimal, but it seems to me that the advantage of
> > watcher reusage strongly depends.
> You could post your benchmark script. At least we could see what you
> are doing...
Well, ok. Here it comes. But first, as I expressed earlier, I agree that this question
might not be that important (as I thought first when I started this point of discussion
(to quickly?!)). So the script is just for interest.
To get the benchmarks, I called it this way:
time perl pool.pl >& /dev/null
time perl pool.pl -pool >& /dev/null
several times.
It should work the following way: the idle watcher starts a number of IO watchers which
immediately cancel themselves until the idle watcher was called a certain number of
times, then it terminates the event loop and therefore the script.
The idle timeout is set to a low value to avoid wasting time by waiting for the next
idle call (which could falsify the benchmark). The io watcher timeouts are set to
extremely low values to guarantee an immediate destruction. Priority settings should
result in performing all io watcher handling of a current loop before the idle watcher
starts next.
IO watchers are built via constructor without option -pool, and from a pool of prebuilt
watchers if -pool is set.
The number of watchers built and destroyed a loop (between two idle events) is
determined by the constant WATCHER_NUMBER.
Jochen
P.S.: Your statements that there may be other parts to be optimized are very well
illustrated by the fact that I used a "complex" trace method check() first - because I
derived the script from another one - which strongly influenced the result as I
detected
after replacing it by almost nothing.
pool.pl
