Performance of Multiple Event Subscribers in Business Central

The Situation

With newer versions of Business Central, it's now possible to have multiple page and table extensions for the same objects within a single app. This flexibility allows us to build apps in a modular way and group functionality together thematically.

However, this raises an interesting question: How should we handle event subscribers?

The Old Mindset

Traditionally, we often created one codeunit per functional area that subscribes to all events from that area in Business Central - for example, all sales-related events. The reasoning behind this was always:

"Subscribing to an event multiple times must be expensive!"

But is that really true? Or are we holding ourselves back from organizing our code more cleanly and modularly based on a false assumption?

The Performance Test

To answer this question, I conducted a practical comparison test. The test scenario was simple:

• An integer value should be increased by a total of 100 through event subscribers
• The test is executed 500 times

Variant 1: One Event Subscriber

A single event subscriber that calls an AddOne() function 100 times:

[EventSubscriber(ObjectType::Codeunit, Codeunit::"PTE Process Subscription", OnFireOneEventSubscription, '', false, false)]
local procedure ProcessSubscription_OnFireOneEventSubscription(var i: Integer)
begin
    AddOne(i);  // Called 100 times
    AddOne(i);
    AddOne(i);
    // ... total of 100 times
end;

Variant 2: One Hundred Event Subscribers

One hundred separate codeunits, each subscribing to the same event and increasing the value by 1 only once:

codeunit 57040 "PTE Test ES 1"
{
    [EventSubscriber(ObjectType::Codeunit, Codeunit::"PTE Process Subscription", OnFireOneHundredEventSubscription, '', false, false)]
    local procedure ProcessSubscription_OnFireOneHundredEventSubscription(var i: Integer)
    begin
        AddOne(i);  // Only once
    end;
}
// ... 99 more identical codeunits

The Results

After 500 executions, the results were clear:

Conclusion: Clean Code Wins!

Yes, 100 event subscribers are approximately 4x slower than a single subscriber. But let's look at this in context:

• 72 ms for 500 executions = approx. 0.144 ms per execution
• In real scenarios, we rarely have 100 subscribers for a single event
• The additional cost is minimal in absolute terms

My Recommendation

The performance cost is not high enough to justify writing messy code!

Instead of bundling all event subscribers into one "god codeunit," we should:

✅ Place event subscribers where they thematically belong

• Close to the related functionality
• In the corresponding feature codeunit
• Together with the related business logic code

✅ Prioritize modularity and maintainability

• Smaller, focused codeunits
• Clear responsibilities
• Easier debugging

✅ Readability over micro-optimization

• Code that others (and you in 6 months) will understand
• Self-documenting code through clear structure