Preliminary investigations show that the following benefits can be obtained with the proposed solution:

Throughput

More than a 10% performance increase in the EventLoop. (handlers/s invoked)

Latency Percentiles

About 7% latency reduction at six nines (us)

Average Latency

About 4% reduction of the average latency (ns)

Potential Drawbacks

IsolatedEventLoop would be less favorable in cases where handlers are added and removed relatively often or in cases with a large number of handlers with mixed priority.
If we add a method runOnce(), the drawback of adding and removing short-lived handlers could be mitigated.

Test setup:

from chronicle-threads.

The most common case is a small number of medium handlers
The performance of these can be improved by loop unrolling for this use case.

from chronicle-threads.

The improved VanillaEventLoop (85ebc2e) compared with only 4 medium handlers stacks up like this compared to IsolatedVanillaLoop:

from chronicle-threads.

There is also MediumEventLoop which Peter introduced in December. We should apply optimisations to this too or else get rid of it.

@peter-k-lawrey did you mean for EventGroup to use it like this?

        core = priorities.stream().anyMatch(VanillaEventLoop.ALLOWED_PRIORITIES::contains)
                ? corePriorities.equals(EnumSet.of(HandlerPriority.MEDIUM))
                ? new MediumEventLoop(this, name + "medium-event-loop", pauser, daemon, binding)
                : new VanillaEventLoop(this, name + "core-event-loop", pauser, 1, daemon, binding, priorities)
                : null;

from chronicle-threads.

@peter-k-lawrey I've made the change above

from chronicle-threads.

@JerryShea and @minborg - I assume that this can now be closed, please reopen if you feel there is more to do.

from chronicle-threads.

Released in Chronicle-Threads-2.20.102, BOM-2.20.173

from chronicle-threads.