The return of the performance leak - this time with subreports
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.Do you have slow workbooks due to size bloat? Give us a try at speeding up.
Hey Folks - Do you have slow workbooks due to size bloat? If so, then I am super excited to unveil Check Performance, Excel Performance team’s new capability to detect and remove size bloat due to unwanted formatted cells and speed up your workbooks. It is currently available to Excel M365 subscribers on the web.Excel performance improvements now take seconds running Aggregation functions
I’m excited to announce that faster Aggregation and RealTimeData functions are available in the latest M365 Monthly and Semi-annual preview channels! This is our next wave of Excel M365 performance improvements after Speedy Lookups to reinforce our commitment to making Excel M365 the new gold standard of Excel Performance. This time around we have even more improvements, starting with...
