Unacceptable performance RRS feed

  • Question

  • I've seen a bunch of threads on here complaining about slow reports, but there doesn't ever seem to be a solution. And on a lot of threads, not even a response. 

    I've been trying to fix an unrelated problem with a resource leak related to deploying Report Viewer with ClickOnce. More information is listed HERE

    The test solution I presented in the above link is as simple of a report as you can create. It's simply a new rdlc file with no changes and is ran in an infinite loop rendering to PDF with LocalReport. This works fine when ran without debugging from VS. These blank reports run somewhere between 50 and 100ms. It seems it doesn't matter what VS, .NET, or ReportViewer version. It still runs fast.

    However, deployed with ClickOnce, it gets crazy slow. If I recall, ReportViewer 2012 was running around 2 seconds and ReportViewer 2015 was close to 20. Report Viewer version 14 (I assume that is also considered to be 2017) is back to around 2 seconds. The only situation where it's not slow was a deploy using Report Viewer 2008 and .NET 3.5.  With that configuration, it's still around 50 to 100ms.

    I've read mention of trying things like <NetFx40_LegacySecurityPolicy enabled="true" />. I've tried that in my actual application, but my reports are still at least an order of magnitude slower than they are with ReportViewer 2008 and .NET 3.5.

    I fired up my profiling software to take a look at what is happening to take all this time. It appears the vast majority of the time is spent by ReportViewer serializing with a BinaryFormatter inside IntermediateFormatWriter. Does anyone know if there's a reason it's doing all this serialization?

    Are there any settings I might try changing? My gut says I can't do anything about all this serialization going on. I really don't want to have to revert back to ReportViewer 2008 and .NET 3.5, but I may have to.

    As a side note, I assume ReportViewer is not one of the things Microsoft has open sourced. That's too bad because I think it needs a lot of work.

    Thursday, November 9, 2017 8:27 PM

All replies

  • I should also clarify, the "empty report" is fast when ran directly from VS, but my actual reports are much slower even when running from VS.
    Thursday, November 9, 2017 11:56 PM
  • I wrote a test harness to show that there's a problem. I took a report from one of my production systems and anonymized the data. I created separate projects for each combination of Report Viewer (2008, 2012, 2015, 2017) and .NET version (3.5, 4.0, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1) that I had installed on my system. This was all done in a VS2017 solution. Initially, I was using the 2005 rdlc definition in all projects, but then I upgraded the ones that supported the 2008 format just to see if it made a change, which it didn't.

    The test harness lets me provide parameters. The report basically represents a list of payments made for an applicant. Each applicant can have multiple cases. Each case can have multiple payments. I also added a timeout parameter because some of the reports were taking a long time (or perhaps infinite amount of time) to run.

    First test was very simple. One applicant, one case, and 5 payments. It seems Report Viewer 2008 is at least twice as fast as newer versions. I was hoping newer Report Viewer would be faster, so this, by itself, is a major letdown.

    Thursday, November 16, 2017 12:58 AM
  • Moving on was a test of 200 applicants, 1 case, and 5 payments.

    As expected, Report Viewer 2008 took a little more time to process, but still reasonably fast. However, now newer versions are about 5x-6x slower.

    Thursday, November 16, 2017 12:59 AM
  • Moving on to 1000 applicants, 1 case, 5 payments.

    Once again, Report Viewer 2008 is taking a reasonable amount longer. Newer versions have started to go really crazy. Anything running on .NET 3.5 won't even finish. I even let one of those run overnight. Newer than .NET 3.5 will execute, but now it's looking like 8x slower.

    Thursday, November 16, 2017 1:02 AM
  • And finally, I ran a 2000 applicant, 1 case, 5 payment test. 

    Once again, acceptable performance between 25s and 34s from Report Viewer 2008 tests. Everything else times out after an hour. I have to wonder if they would ever finish. 

    Thursday, November 16, 2017 1:05 AM
  • These tests generate PDF files using LocalReport. With the case count and payment counts specified, the number of pages in the resulting PDF is the same as the number of applicants.  So, for instance, the last test would generate 2000 page pdfs.

    We have the potential for reports that generate mailings. These could be more complicated than this report is and we're talking in the order of tens of thousands of pages. I suspect with Report Viewer 2008 that would be no sweat. Maybe a few minutes of rendering time. But I have no clue whether any newer Report Viewer would ever finish rendering.

    For some background, we've been using VS2008 and ReportViewer 2008 for our main application. Recently we upgraded, as we would like to use newer programming features and some of our add-ons are likely to stop supporting as old of a VS version as we have. We would be happy to keep using ReportViewer 2008, except I don't believe we can use the report designer in newer versions of VS without upgrading our rdlc files. And that would require a newer Report Viewer version, so we're kind of stuck.

    What I was hoping was to get some feedback on whether anyone else has had these problems? Does everyone just give up on using Report Viewer and migrate to some other project? We have so many reports that I don't really want to do that. 

    I am thinking about submitting this as a bug to MS, but would prefer to get some feedback first, in case there's something I'm not doing correctly.

    Thursday, November 16, 2017 1:13 AM
  • I should add, if anyone wants a copy of my test harness, I can post a link here.
    Thursday, November 16, 2017 1:18 AM
  • I would be very interested in the test harness app. I am experiencing terrible performance with ReportViewer and large datasets (local method)
    Sunday, July 29, 2018 8:18 PM
  • I think this thread has a link to it: That link is

    It's been so long I pretty much forgot about it. After not getting any help from Microsoft, I just gave up and write all my reports in 2008 (which requires I use VS2008), then copy them over to my 2017 solution. Really annoying, but it's all I could think to do to maintain any level of performance.

    Sunday, July 29, 2018 8:32 PM
  • Thanks very much. I am really frustrated with the performance I am seeing. Stored proc comes back fast but report takes 4-5 minutes to render. I am seeing no solutions to this other than your post
    Sunday, July 29, 2018 8:47 PM
  • It seems like MS is really dropping the ball a lot. And not just this, but I've tried to post test harnesses on both the new Microsoft Connect and on whatever their old bug tracking site was. Neither one had upload functionality that actually worked, which is why I had to do the dropbox link.

    Really frustrating to have to spend that much time just getting a bug report in, just to have nobody look at it. Or should I say, they look at it but say they are prioritizing customer needs and apparently reporting isn't high on that list.

    My boss even paid for an Enterprise license hoping the extra support would help, but that got me nowhere either.

    Sunday, July 29, 2018 8:56 PM