Hacker News new | ask | show | jobs
by jfager 5621 days ago
you get between 5000-1000 executed events per second

As a point of comparison, I put together a quick Python script that defines a simple single-threaded event dispatcher and then does the same thing as your testPerformance() test, and it handles over 296k events/s on my machine (where javaEventing handles 3.7k).

This use of multi-threading is used to achieve full asynchronisity

The way that you're currently synchronizing, the only concurrency you're seeing is for your handlers. You only trigger and dispatch out to handlers one event at a time.

There are two scenarios where threads are always going to be unavoidably slow: high contention, and processor-bound tasks with more threads than processors. Your current synchronization policy pretty much assures you're going to run into high contention, and if you're using this for processor-bound tasks, you're going to pay a severe tax for the number of threads you're generating, as well.

Put in the threadpool. Take a look at ConcurrentHashMap and CopyOnWriteArrayList. Work on your synchronization policy. High throughput concurrency and eventing is hard, but Java actually has a lot of nice building blocks to work with. If you want a good overview, you should check out Brian Goetz's Java Concurrency in Practice.

1 comments

The updated version (from 1.3.0) of the library uses a thread-pool, and yields between 50.000-100.000 events/second. While I apprechiate your focus on performance, for most actual use this would be academic. In most cases, even 10.000 events per second would be sufficient.