Anyone remember the v2405 bug that caused loading and closing forms to become slower over time?

We found something similar in the current release (tested with semi-annual 2508 (19127.20484)), just with sub reports instead of forms. Here are the repro instructions:

Repro instructions

Table

1. Create a "numbers" table with a PK field "nr" (Long Integer).

2. Fill it with the numbers from 1 to 100:

Dim i
For i = 1 To 100
    CurrentDb.Execute "INSERT INTO numbers (nr) VALUES (" & i & ")"
Next i

Sub report

3. Create a new empty report in design view, using the "numbers" table as the record source.

4. In the detail section, add two text boxes "Text1" and "Text2" next to each other, both with the "nr" field as their control source.

5. Reduce the size of the detail section to one "row", containing just the two text boxes. Remove the page header/footer.

6. Add an Format event handler to the detail section with the following content:

Me.Text2.Visible = False

7. Save the report as "sub".

Main report

8. Create another report "main", which contains nothing but the "sub" report as a subreport in its detail section. Set the record source of "main" to "SELECT * FROM numbers WHERE nr <= 10"

Reproduce problem

9. Create the following method in a module:

Sub report_loop()
    Dim i As Long
    Dim start_time As Single
    Dim report_name As String
    Dim path As String

    report_name = "main"

    For i = 1 To 40
        path = Environ("Temp") & "\testreport.pdf"
        
        start_time = Timer
        DoCmd.OpenReport report_name, acViewPreview
        DoCmd.OutputTo acOutputReport, report_name, acFormatPDF, path
        DoCmd.Close acReport, report_name
        Debug.Print Timer - start_time
    Next
End Sub

10. Run report_loop. Observe that each report export gets slower and slower.

Analysis

Compare the first and last number in the direct window: on my machine it's 0.4s for the first report and 2.3s for the last.

Note that if you run report_loop again, it will start slow! In other words, each report export causes MS Access to "leak performance" that is only regained after restarting Access.

We were able to reproduce this issue with Microsoft 365 semi-annual channel, Version 2508 (19127.20484). I'll do more tests tomorrow and try different older versions to find out when this bug was introduced.

Workarounds

If you move the visibility code from the Format event to the Print event, the problem still occurs, but slower (0.4s -> 0.72s instead of 0.4s -> 2.3s).

The workaround that worked for us was to use =IIf(...) in the control source instead of modifying the visibility. Obviously, that only works for text boxes, not for lines or other controls.