in reply to AnyEvent for I/O events

Great article about great module. I think AnyEvent might be real standard for event driven applications.

I would like to see some benchmarks and see if multi-threaded application is faster that one-threaded with event loop. I already found some Java benchmark (http://www.theserverside.com/discussions/thread.tss?thread_id=26700) and saw that Linux with NPTL and one connection per one thread mode can be really faster than many connections per one thread mode.

Replies are listed 'Best First'.
Re^2: AnyEvent for I/O events
by elmex (Friar) on Apr 16, 2008 at 19:58 UTC

    The performance of AnyEvent depends on the event loop used. If you use EV as event loop it will most likely be VERY fast and scalable (as the author of EV/libev optimized it a lot, see also: libev vs. libevent benchmark). If you use Tk or Glib as event loop the performance might not be the best.

    AnyEvent is after all just a very thin abstraction layer.

    The performance benchmark of multi-threaded vs. one-threaded with event loop is mostly a comparison of apples to bottles of beer:
    For example: If you just have two threads per socket: one reader and one writer, your performance will most likely suck a lot, especially when your connection count rises that design wont scale well. But you could have an event loop per thread, and each thread could handle a specified amount of connections, which could be a way better solution.

    So threads and event loops are after all two very orthogonal concepts.

    Also note that enabling threads when compiling perl5 will degrade the overall performance of that perl5 build.