Most pricing libraries and derivative systems have a Business Day Calendar object which can determine if a specific date is a good business day or not. The natural implementation of BUS/252 is to iterate through each day in the calculation period checking if it is a good business day and divide the count by 252. However, this implementation can be unsatisfactory from a performance perspective when the calculation period is relatively large; for example, options can have expiries of several years.
A refined implementation, which is often faster, is to pre-compute and cache the count of the number of business days over predetermined short intervals; for example, each month. Then any calculation of the number of business days is limited to directly counting the number of business days in the stub period at the start of the calculation period and the number of business days in the stub period at the end of the calculation period and summing the pre-computed counts of the periods between.
To illustrate the idea, consider for example a calculation period of 3-months between 20-Aug-2012 and 20-Nov-2012, and suppose we have precomputed the count for each month.
To calculate the number of business days between 20th August and 20th November we first check and count each business day in the period 21st August until 31st August. For the period 1st Sept to 30th Sept, we do not check each date, but lookup the cache for the count of business days in Sept, similarly for the period 1st Oct until 31st Oct. Finally, we check and count each business day in the period 1st-Nov to 20th Nov. Overall we have reduced the number of calls to the Business Calendar object to about 30. Indeed any calculation of BUS/252 can be reduced to calling the Business Centre Calendar object a fixed number of times regardless of the size of the calculation period.
When deciding intervals to cache, it is useful to consider the structure of one’s date object to ensure a fast cache lookup. If it represented as a Gregorian date (YYYY-MM-DD), then using a cache which represents a period of one month, or a number of months, is natural. If the date object is represented as a serial number such a Julian date, then the caching interval would more naturally be a fixed number of calendar days, say 32.
An implementation of this idea is found in QuantLib since v1.2. In their implementation, they actually cache both monthly periods and yearly periods.
Update 28th Oct 2015
One point of confusion can arise concerning the first and last day of the accrual period when counting business days, especially if these dates are business days. Generally, the first day is included and the last day is excluded.