.rpt files very slow to open in CR9 on local machines

[caimoss]

We have about 40 reports in one application. When the dev team is working on them, certain reports take a long time to simply open up in CR9 for editing--no record selection, no access across the network. The files are checked out of source code control, put in a local folder, and then worked on by the developer.

Is there anyone who knows of something that can cause this? Here are a few of the items we've already tried based on various searches in the forums here and some (un)help from BO (I don't think they quite understand our problem yet, but we keep trying).

1. No reports are "Saved with Data". Not even the subreports in a report.

2. Many of our reports do have a large number of subreports, but we've disproved the idea that the ones with the most subreports always take the longest to load (clearly, you could argue one really complicated subreport might have a bigger impact than a handful of very simple ones, but in this case most of our subreports are similar in nature). We have one report with 19 subreports--takes 66 seconds to open on average. I am in the process of rebuilding this report from scratch, and with 10 of the 19 subreports in there now, it's up to a grand total of 3 seconds to load (this information comes from the menu Report-->Performance Information). I'm beginning to think even after the whole report is rebuilt I'm not going to get back to the 66 seconds.

3. We have tried opening the report in CR9-Advanced and CR9-Developer. There is no difference in the load time.

4. None of the subreports in any report are set to "re-import when opening".

One unknown which we're trying to validate but is very time-consuming to do, is that the reports were inherited from previous developers. Unsure of the exact hotfix/service pack they had on their CR9 installations.

The bigger problem is that when these reports are published to our Standalone RAS server, even RAS has to wait for the 66 seconds (in this example) for the report to open before it can render the report. This is causing a severe perceived performance hit, as we have performed timings in code that validate all of our data selection and report viewer "paint times" aren't causing the problem.

I'm hoping that there is something that just "happens" to the report during its lifetime that causes this slowdown. If it's even a manual process to avoid doing something that causes this (e.g., "don't use feature XYZ"), we'll give that a shot.

Thanks!

 

[caimoss]

Ack...forgot to mention. In our "worst offender" example (the 66 second report), I hacked out 15 of the 19 subreports. The remaining four subreports are used in just about every one of our reports (standard header and footer stuff), so I left them in there to compare overall load times with many of our other reports.

Even after having done that, the "worst offender" still takes 66 seconds to load. This is one of the other items that leads me to believe having a ton of subreports, while certainly a performance hit, is not the specific reason this is happening. Other reports which contain these same 4 subreports take mere seconds to open.

 

[caimoss]

In case anyone cares...turns out it was a problem with the subreports. I just hadn't gotten to the right ones yet, and it all depends how you import them.

http://support.businessobjects.com/library/kbase/articles/c2014546.asp

In one report, the four subreports were imported by a developer from local copies they had. In another report, the four subreports were imported over a UNC-mapped drive. Even though both reports used the same exact four subreports, the latter one has the problem b/c of how they were imported.

If you're looking for a performance improvement in CR or even in CE or CE-RAS, this is worth checking out in your reports. We shaved that 66 second report down to 2 seconds by reimporting the reports from a local folder (we are unable to apply the hotfixes as they actually break some other functionality we need).