Date/Time Calculations Can Be Surprisingly Expensive

Performance tip for IBM i developers and operations teams

When analyzing performance data from high-volume batch jobs – for example, interest calculations on millions of records at large banks – we’ve often found that date and time routines consume more CPU than anything else.

‍

Why? Because even though these functions are convenient, they are not cheap in terms of performance.

‍

In this article, I’ll explain why that is – and how a simple trick can save hours of processing time.

How date and time are stored internally

 IBM i uses a 64-bit internal clock that increments every microsecond. This value is often used as a timestamp. The origin time of this clock – 12:03 PM on August 23, 1928 – was deliberately chosen, such that the most significant bit would change (“roll over”) at the change of the millennium. Clever design, but it makes conversions a bit more complex. 

‍

Luckily, the system provides built-in functions and APIs to help. Retrieving and formatting a timestamp isn’t too costly on its own. But when you start doing calculations – adding, subtracting, comparing timestamps across millions of records – things get expensive fast.

‍

This is because our calendar system isn’t exactly CPU-friendly. Months and years vary in length, time units are irregular, and formats often need conversion from character to numeric and back.

A smarter approach: use lookups

Our servers are fast, yes – but if you’re running the same date calculation millions of times, you’re wasting a lot of CPU.

‍

Instead, we recommend a lookup strategy:

• Create a binary table or user index where the key is an older date, and the value is the number of days between that date and today.
• Before calculating, check if the result already exists in the table.
• If it’s there – great, you’ve avoided the heavy calculation.
• If not – calculate once, store it, and reuse.

We’ve seen this save up to 90% of the CPU otherwise used in repetitive date/time operations.

Locating optimization potential for Date/Time calculations

GiAPA makes it easy to spot such inefficiencies. For any job that uses significant resources, we automatically retrieve the call stack and highlight where time is spent – including heavy use of date/time routines.

‍

You can also check manually using IBM tools:

• Run DSPJOB OPTION(*PGMSTK) on the job and press F5 repeatedly.
• If you see a lot of QRNXDATE or QRNXTIME (in RPGLE applications), you likely have a performance issue worth investigating.