| … | |
… | |
| 948 | The C<Tk> adaptor works relatively well. The fact that it crashes with |
948 | The C<Tk> adaptor works relatively well. The fact that it crashes with |
| 949 | more than 2000 watchers is a big setback, however, as correctness takes |
949 | more than 2000 watchers is a big setback, however, as correctness takes |
| 950 | precedence over speed. Nevertheless, its performance is surprising, as the |
950 | precedence over speed. Nevertheless, its performance is surprising, as the |
| 951 | file descriptor is dup()ed for each watcher. This shows that the dup() |
951 | file descriptor is dup()ed for each watcher. This shows that the dup() |
| 952 | employed by some adaptors is not a big performance issue (it does incur a |
952 | employed by some adaptors is not a big performance issue (it does incur a |
| 953 | hidden memory cost inside the kernel, though). |
953 | hidden memory cost inside the kernel, though, that is not reflected in the |
|
|
954 | figures above). |
| 954 | |
955 | |
| 955 | C<POE>, regardless of underlying event loop (wether using its pure perl |
956 | C<POE>, regardless of underlying event loop (wether using its pure perl |
| 956 | select-based backend or the Event module) shows abysmal performance and |
957 | select-based backend or the Event module) shows abysmal performance and |
| 957 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
958 | memory usage: Watchers use almost 30 times as much memory as EV watchers, |
| 958 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
959 | and 10 times as much memory as both Event or EV via AnyEvent. Watcher |
