Business Central 26: Dramatic Performance Improvement for Callstack Checks

Back in 2016, I wrote a blog post about how to check if your code was being called from a specific function using a try function and an empty error to access the callstack via GETLASTERRORCALLSTACK. For example, checking if you were inside a SaveReportAsPDF function.

This technique was useful but came with a performance penalty.

The Game Changer: Business Central 26

With Business Central 26, Microsoft introduced direct access to the callstack at any time, eliminating the need for the error-based workaround. This isn't just a cleaner approach – it's dramatically faster.

Performance Comparison

I ran a benchmark with 500 calls using both methods:

• Old method (try function with error): 491ms
• New method (BC 26 callstack): 58ms

That's a 88% performance improvement! The new approach is over 8 times faster.

The Old Approach (2016)

Here's how we used to do it with the try function pattern:

local procedure IsPdfPrint(): Boolean
begin
    if not ThrowEmptyError() then
        exit(GetLastErrorCallStack().Contains('SaveReportAsPDF'));
end;

[TryFunction]
local procedure ThrowEmptyError()
begin
    Error('');
end;

This method required:

1. A try function to catch the error
2. Deliberately triggering an error
3. Parsing GETLASTERRORCALLSTACK to find the calling function
4. Overhead from error handling

The New Approach (Business Central 26+)

With BC 26, we can access the callstack directly:

local procedure IsPdfPrint(): Boolean
begin
    exit(SessionInformation.Callstack().Contains('SaveReportAsPDF'));
end;

The new method is:

• Significantly faster (58ms vs 491ms for 500 calls)
• Cleaner code – no need for error handling tricks
• More maintainable – straightforward and easy to understand
• Available anytime – no need to trigger an error first

Should You Migrate?

Absolutely! If you're on Business Central 26 or planning to upgrade, replacing the old try-function pattern with direct callstack access is a no-brainer:

✅ 88% performance improvement
✅ Cleaner, more readable code
✅ No error handling overhead
✅ Better maintainability

Conclusion

This is a perfect example of how Microsoft continues to improve the AL language and runtime. What once required a clever workaround is now a built-in feature that's both more elegant and significantly faster.

If you're still using the old try-function approach for callstack checks, it's time to upgrade. Your code will thank you with better performance and improved readability.