Hello Scott,

I'd like to thank you for the feedback. We always take time to read and discuss the input from our clients, because we understand that their feedback reflects a particular business scenario that we are not supporting yet or we haven't clearly explained how a particular functionality works.

After discussing the current feature request with the development team, I'm inclined to put it to the second group and below I will try to explain why.

First, we don't believe that caching the data "behind" a drill-down action will improve the performance or conserve the machine's resources. Ideally, the data retrieval process should not take significant amount of time. As a rule of thumb, the most resource- and time-consuming part of the report rendering is the paging stage, where all the items have their positions calculated and the report contents are being output to the corresponding rendering format (writing HTML markup, drawing on an image canvas, creating a PDF stream, etc.). In case the dataset of the report contains a lot of data, but the report consists of a simple crosstab that shows the data aggregated in a few textboxes, I would recommend considering server-side optimization - maybe it makes sense to group the data in the database rather than transporting all the data to the reporting engine. Of course, it can handle huge loads of data, but processing and aggregating it takes some time that might degrade the user experience. I'm not familiar with your scenario, but if in your case the data retrieval is the slowest part of the process, I suggest to consider using ObjectDataSource and implement custom data caching in the data retrieval class. You can find more ideas about data retrieval optimization in the blog post Best Practices For Data Retrieval and I suggest to check it out.

Second, when a drill-down action occurs, the report must be rendered again, because this action might cause a change in the page count, therefore all the places where the page functions are used, must be re-evaluated again. It's way simpler (and safer) to render the document anew rather than "update" only the parts that need to be changed. The paging algorithm kicks in even in interactive mode, where the so-called "soft page-breaks" are used, so there's no way to spare it from the whole rendering process. For more information on how our engine works, I recommend having a look at our Next Level Report Engine Explained blog post.

Third, you can use the caching capabilities of our REST service engine. When a report is rendered by the reporting engine, it is persisted in the storage for a period of time determined by the ReportSharingTimeout property. When persisted, we construct a specific key that represents the report state: the rendering format, the report parameter values, and the state of the drill-down items. When the client (the Report Viewer) initiates a new report rendering with the same state, the already rendered report is obtained from the cache instead of rendering it again. This can be observed in our demo you mentioned - when you expand-collapse-expand the same drill-down item, the second and third renderings are way faster, because the service returns the already rendered report from its cache, rather than rendering it anew.

I hope I managed to explain why we designed the behavior of the drill-down actions this way. Changing this behavior is not in our current plans and I'm afraid I will have to set the Feature Request's status to Declined.

Please if you disagree with anything of the explanations above or your scenario is different than the assumptions I made in my answer, do not hesitate to contact us and share more details about it.

Regards,
Dimitar
Progress Telerik