We've seen occurrences of fines.pl and overdue_notices.pl slowing down when there are a large number of (usually old) entries in special_holidays table. Apparently, we're checking each candidate day against the whole fines calendar -- this is unnecessary, as both fines and overdue notices are are bounded; we only need to check the calendar enteries between the current day and the relevant letter delay (for overdue notices) or between the day the item went overdue and the current day (for fines). If we could pass in a start and end date, we could eliminate this overhead.
Well.. we could easily switch from an array which we iterate to a hashref we can to a direct lockup on within the single_holidays method.. that would be a good first step I think. The caveat is that we trade some RAM for performances.. but I don't think it was a deliberate act to choose and array over a hashref in the first place.
Created attachment 105843 [details] [review] Bug 18519: Use a hasref for lookup Rather than using an array of dates and iterating them, use a hashref and do a direct lookup
So, this made a really significant impact on fines and checkout times on one of our live servers.. The customer in question has added the entirety of Covid Lockdown as special holidays to allow for proper fines calculations for items that went overdue just prior to lockdown.
*** This bug has been marked as a duplicate of bug 25723 ***