SSRS Report Performance Thoughts – To calculate on the report, or in your X++ code
For this blog post, I have been thinking about different ways data can be aggregated for SSRS Reports. When doing subtotaling on reports, you generally do an expression that resembles something like this:
You can also do this type of aggregation for a total in a row based on multiple fields.
Here is the dilemma, is it faster or more efficient to do this type of work on the SSRS report itself, or do it in the Report Data Provider logic (totals in a ROW, not a group subtotal) class logic, and pass the data to SSRS as a field in a table?
My personal feeling on this is that I like to do the work up front (in the X++ code) and pass the final total into the field, instead of doing the calculations on the SSRS report. You will be passing a bit more information to the report (an additional column or two), but you are saving the report from having to do the calculation at render time, which should cause the report to render more quickly.
If you are working with a preprocessed SSRS report, why not do the work first, and make it easy on the report renderer? This concept really is similar in thought to what we teach in X++ Development best practices. Use the aggregate functions to get a record back instead of a loop to do totals (you may loop through THOUSANDS of lines to do your total calculation), or use JOINS instead of nested while selects to get data in select statements. You tend to rely on the database engine to do the work for you instead of the code. Do the same for the report whenever possible, and have the ‘heavy lifting’ completed by the time the data gets to the report.
Please note that I have NOT done any ‘official’ type testing to measure execution time differences, but to me this thought exercise really follows the Development Best Practices that we try to instill in AX Developers, so why not have this flow into report design as well.
I welcome any discussion or feedback on the above.