| … | |
… | |
| 1071 | file descriptor is dup()ed for each watcher. This shows that the dup() |
1071 | file descriptor is dup()ed for each watcher. This shows that the dup() |
| 1072 | employed by some adaptors is not a big performance issue (it does incur a |
1072 | employed by some adaptors is not a big performance issue (it does incur a |
| 1073 | hidden memory cost inside the kernel which is not reflected in the figures |
1073 | hidden memory cost inside the kernel which is not reflected in the figures |
| 1074 | above). |
1074 | above). |
| 1075 | |
1075 | |
| 1076 | C<POE>, regardless of underlying event loop (whether using its pure |
1076 | C<POE>, regardless of underlying event loop (whether using its pure perl |
| 1077 | perl select-based backend or the Event module, the POE-EV backend |
1077 | select-based backend or the Event module, the POE-EV backend couldn't |
| 1078 | couldn't be tested because it wasn't working) shows abysmal performance |
1078 | be tested because it wasn't working) shows abysmal performance and |
| 1079 | and memory usage: Watchers use almost 30 times as much memory as |
1079 | memory usage with AnyEvent: Watchers use almost 30 times as much memory |
| 1080 | EV watchers, and 10 times as much memory as Event (the high memory |
1080 | as EV watchers, and 10 times as much memory as Event (the high memory |
| 1081 | requirements are caused by requiring a session for each watcher). Watcher |
1081 | requirements are caused by requiring a session for each watcher). Watcher |
| 1082 | invocation speed is almost 900 times slower than with AnyEvent's pure perl |
1082 | invocation speed is almost 900 times slower than with AnyEvent's pure perl |
|
|
1083 | implementation. |
|
|
1084 | |
| 1083 | implementation. The design of the POE adaptor class in AnyEvent can not |
1085 | The design of the POE adaptor class in AnyEvent can not really account |
| 1084 | really account for this, as session creation overhead is small compared |
1086 | for the performance issues, though, as session creation overhead is |
| 1085 | to execution of the state machine, which is coded pretty optimally within |
1087 | small compared to execution of the state machine, which is coded pretty |
| 1086 | L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow. |
1088 | optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that |
|
|
1089 | using multiple sessions is not a good approach, especially regarding |
|
|
1090 | memory usage, even the author of POE could not come up with a faster |
|
|
1091 | design). |
| 1087 | |
1092 | |
| 1088 | =head3 Summary |
1093 | =head3 Summary |
| 1089 | |
1094 | |
| 1090 | =over 4 |
1095 | =over 4 |
| 1091 | |
1096 | |
| … | |
… | |
| 1170 | |
1175 | |
| 1171 | =head3 Summary |
1176 | =head3 Summary |
| 1172 | |
1177 | |
| 1173 | =over 4 |
1178 | =over 4 |
| 1174 | |
1179 | |
| 1175 | =item * The pure perl implementation performs extremely well, considering |
1180 | =item * The pure perl implementation performs extremely well. |
| 1176 | that it uses select. |
|
|
| 1177 | |
1181 | |
| 1178 | =item * Avoid Glib or POE in large projects where performance matters. |
1182 | =item * Avoid Glib or POE in large projects where performance matters. |
| 1179 | |
1183 | |
| 1180 | =back |
1184 | =back |
| 1181 | |
1185 | |
