none
Asp.Net Reportviewer control printing report with 7 pages takes 10 minutes! RRS feed

  • Question

  • We have a report, with about 15 barcode images per page, that takes at least 10 minutes to print only 7 pages. We are using PNG images and have the image set to FitProportional. We are using VS2008 with the Asp.Net ReportViewer control. We are binding to custom objects which contain the image bytes. We are using a client/local report (RDLC).

    Does anyone have any advice on how to improve that performance?

    UPDATE: I used Fiddler (an HTTP Proxy) to see the traffic between the browser and the report and the first page is rendered in about 1 minute with a request to print from StartPage=1 and EndPage=1. The next request takes around 5 minutes and requests the rest of the pages with StartPage=2 and EndPage=65535.

    UPDATE: I changed the image type from PNG to JPEG and the time went down to 3 minutes to print 7 pages. That is great but still quite some time. I'm going to play with the quality of the JPEG to see if I can get it any faster.
    • Edited by Jon Dalberg Monday, March 1, 2010 7:35 PM Added JPEG info
    Friday, February 26, 2010 3:38 PM

Answers

  • Or reduce the size of the images so that report processing and the output use less memory.  I would certainly investigate if you can reduce the resolution on the images and still achieve the printing you want.  For barcodes, you might also want to make sure you generate black and white images rather than full 32 bit color images.  That could save a lot of memory too.
    • Marked as answer by Jon Dalberg Wednesday, March 3, 2010 8:01 PM
    Tuesday, March 2, 2010 5:56 PM
    Moderator

All replies

  • Do you know how big the images are?  I wonder if that is causing you to send a very large amount of data back and forth or using a significant amount of memory, which is often a problem for local mode.

    You can determine how much data is being transmitted in a number of ways - the Fiddler trace will show it, when the report is printed the Windows printer status dialog often shows this, or you could manually render the report to EMF and look at the size of byte array that is returned.

    Sunday, February 28, 2010 6:47 PM
    Moderator
  • The amount of data transmitted is rather large. The first page is around 6 MB and the rest is about 40 MB. Each image itself is around 10 KB.

    One of my tests I removed the images and the pages printed very quickly. Then tried with a 1px * 1px image and it was still very fast. The biggest problem is that I need to keep the images rather large so they scale appropriately and are scannable. The images are generated at 750*150px and then placed in an image control on the report with its size set to 2.5" * 0.5" with FitProportional.

    Is there any way to have each page sent as soon as it is rendered rather than building up all the pages and sending them at once? That would improve the perceived performance and potentially solve the current problem.
    Monday, March 1, 2010 2:56 PM
  • That definitely sounds like the problem.  Local mode isn't very good with large reports.  It doesn't have the memory management capabilities of the report server.

    Due to the pagination calculations involved when using a hard page break renderer (one that requires a page of a specific size, such as the EMF renderer, versus something like the HTML renderer), calculating pages one at a time is very expensive.  Calculating page 5, for example, requires the rendering engine to calculate pages 1 through 4 then throw them out.  This is extremely wasteful and incredibly slow if you request pages one at a time.

    If you use the report viewer in server mode, the report server will generate the requested page and continuing processing all remaining pages in the background, giving you exactly the behavior you are looking for.  However, in local mode, there is no storage mechanism available to store the pages generated in the background, so they are all sent back to the client at once.

    The request you see for pages 2 through 65535 does not happen in server mode.  In server mode, you will see requests for each of the pages individually because the report server can cache them.  More information on exactly how this works is available here: http://blogs.msdn.com/brianhartman/archive/2009/02/27/manually-printing-a-report.aspx
    Tuesday, March 2, 2010 4:40 AM
    Moderator
  • Thanks for the information. I had read your post on that before but didn't directly associate it to my problem. So my choices are to move it to a server report or try some other tool/technology?

    Tuesday, March 2, 2010 3:54 PM
  • Or reduce the size of the images so that report processing and the output use less memory.  I would certainly investigate if you can reduce the resolution on the images and still achieve the printing you want.  For barcodes, you might also want to make sure you generate black and white images rather than full 32 bit color images.  That could save a lot of memory too.
    • Marked as answer by Jon Dalberg Wednesday, March 3, 2010 8:01 PM
    Tuesday, March 2, 2010 5:56 PM
    Moderator
  • Yep, changing to a JPEG and reducing the image size was the key. It now takes 20 seconds to print 7 pages with the image at 250x50 (width x height) at 96 DPI and the barcodes scan just fine. Thanks for your help! BTW, Rob Dil a Senior Support Engineer at Microsoft helped quite a bit as well. Thanks to both of you!
    Wednesday, March 3, 2010 8:01 PM