Optimize the rendering time for large groups

[Alma]

Hi.
I work as a freelancer, and right now I have an SME client in the events industry with a dataset of about 15,000 rows grouped by event and then by service provider category. The report runs in a Blazor Server Report Viewer, and it takes nearly 40 seconds to render. I’ve been digging into this seriously for about ten days now. At first, I suspected the data source itself too many columns being loaded unnecessarily—then I looked into the group footers, which recalculate aggregates every time the group changes; that must be putting a significant strain on the rendering engine... Honestly, I haven’t found THE miracle solution yet. I’ve reduced the columns to the bare minimum, and that’s already shaved off a few seconds, but we’re still far from instant rendering. While digging into this issue of constant recalculation on large volumes, I thought about my side project an automated media kit where I also have to manage stats that update daily across multiple platforms (Instagram, TikTok, etc.). So I went back to what I’d looked into for that project, and their approach to daily updates gave me some ideas for rethinking my Stimulsoft-side queries like caching certain aggregates instead of recalculating everything every time the page loads. If anyone has already experienced this kind of slowness with large data groups and found a real fix on the Stimulsoft side, I’d love to hear about it.

Thanks in advance.

[Lech Kulikowski]

Hello,

Thank you for your question. Here are some general recommendations for large grouped reports in Stimulsoft Reports for Blazor:
- Prepare the data on the database side. Group, sort, and aggregate in SQL (or in your code) and pass only the required rows and columns to the report. Pre-calculated totals are much faster than recalculating them in group footers.
- Keep expressions simple. Avoid heavy expressions and many aggregate functions in group footers and on every row, and use built-in aggregates (Sum, Count, Avg) where possible.
- Reduce the work of the engine. Remove unnecessary Can Grow, Shift Mode, and conditions on large bands, and avoid nested sub-reports for big data.
- Cache the data and the report. Load the data once and reuse it between requests instead of querying it on every page load.
Use the viewer’s paging. Render and show the report page by page, and make export (PDF) a separate action.

If the report is still slow, please send us a sample template (.mrt) with a reduced data set and the version of the product, and we will check it.

Thank you.