none
ReportViewer 2010 performance problem in large project RRS feed

  • Question

  • Hi All,

     

    I am facing a very strange issue with the WinForms ReportViewer 2010 control with Local Report rendering.

    I have developed a very simple report based on object datasource, with usually about less than 100 records to display (very basic records consisting in 3 string fields).

    In the first test project (very basic Windows Forms project developed just to design and test the report) everything was fine and the report was taking a few seconds to display.

    When I moved the report and related methods to the main production project I found a dramatic change in performances: now a report takes more than 3 minutes to display.

    After analyzing the behaviour of the application I found the performances start worsening after the application loads a form (bound to about 2000 data records). From this moment (even if I close the databound form) the rendering takes 3+ minutes. The datasource of the report is not correlated to the data displayed in the forms:

    step1: open a fresh instance and create a report -> normal rendering time (from 3 to 5 seconds, OK)

    step2: open a different form in the application and load data (up to 2000 records)

    step3: create the same report again -> the performance problem: 3+ minutes (and memory consumption rises up to 500-600 mb from the initial 200 mb).

    step4: close the form with the loaded records (opened in step2)

    step5: create the same report again -> the performance problem still present: 3+ minutes.

     

    I also tried to load the report in a different application designed only to display the report, with a copy of the report definition (rdlc) defined and compiled in the new reporting application itself to avoid any possible conflict or performance problem loading resources from other assemblies. The "report application" is dinamically launched as a new process with process.start(ProcessStartInfo) but I got exactly the same result: everything ok launching from the test application, ok when I launch from the real application (without opening any form), but 3+ minutes again to render the report if I open the data form and memory consumption of the report application rises to 500-600 mb again.

    The performance of all the other operations is absolutely stable, only the rendering operation (displaying the "Loading" message in the report) changes its behaviour.

     

    Also tested on a different machine with the same results.

     

    I would not like to change to other reporting technologies, but cannot accept this behaviour.

    Any idea on how to resolve the issue?

     

    Thank you in advance

    Alberto

     

    • Moved by Martin_Xie Monday, November 14, 2011 6:55 AM Move it VS Report Controls forum. (From:Visual Basic General)
    Sunday, November 13, 2011 3:41 AM

Answers

  • Hi Matt,

     

    Thank you for your reply and your idea, after your post I tried again with the legacy features, using both the

    <legacyCasPolicy enabled="true" /> and the <NetFx40_LegacySecurityPolicy enabled="true|false"/> settings in the app.config files of all the involved projects, but without success.

    Also tried the related obsolete methods to force the report to be executed in application appdomain since executing in sandbox domain is the default, (LocalReport.ExecuteReportInCurrentAppDomain) but I have always got Invalid Operation Exceptions even while using the configurations to enable the legacyCasPolicy.

    But your troubleshooting ideas and the work to extract a sample project to reproduce the issue gave me the hint to find the solution.

    It is not a ReportViewer bug.

     

    Solution:

     

    1. The report is bound to an object datasource: the datasource is a very simple class used only to pack the report data from the real source (a form with advanced dynamic binding to EF source). This class was exposing the object property for the "original" field value (the EF entity):

     

     Public Class ProductFieldInfo
            Public Property FieldValue As Object
            Public Property FieldLabel As String
            Public Property FieldsGroup As String
            Public Property ValueFormat As String
            Public Property ColumnIndex As Integer
            Public Property SortIndex As Integer
     
            Public ReadOnly Property StringValue As String
                Get
                    Return Me.GetStringValue
                End Get
            End Property
            Public Function GetStringValue() As String
                If IsNothing(_FieldValue) Then Return Nothing
     
                Dim res As String
     
                If String.IsNullOrEmpty(_ValueFormat) Then
                    res = _FieldValue.ToString
                Else
                    res = String.Format("{0:" & _ValueFormat & "}", _FieldValue)
                End If
     
                Return res
            End Function 
     
    

     

    2. In the report I do not use the FieldValue object, but only its string representation (StringValue).

    3. I found that - even if not used in the Report - the FieldValue property is evaluated. This is quite a strange behavior and I would suggest the Microsoft Reporting team to try to avoid it and evaluate only the properties used by the report to render.

    4. Since in the FieldValue field are stored many different objects (many different EF entities), the evaluation of this field was causing an enormous delay because of the interaction with the dataform previously loaded and populated with data from the same EF Entity Container instance: my idea is that all the relations involving the FieldValue values (EF entities) are loaded at "rendering time" for all the records displayed in the dataform: a huge work for the EF Tracking.

    5. The solution: I simply changed the FieldValue property to a private field to avoid the object to be processed.

            Private _FieldValue As Object
            Private _ValueFormat As String

    Now the EF entities are no more visible to the report, and the rendering time normal (a few seconds for the first and a while for the others).

     

    Hope my solution will help, if need more info let me know writing on this post or contacting me by mail.

     

    Many thanks to Matt and Brad for support

    Alberto

     

     

    • Proposed as answer by Matt Meyer - MSFT Friday, November 18, 2011 5:39 PM
    • Marked as answer by Piggy Saturday, November 19, 2011 10:34 AM
    Friday, November 18, 2011 11:40 AM

All replies

  • Hi Alberto,

    Welcome to MSDN Forum.

    Thanks for your valuable feedback.

    These cases discussed the similar issues to yours. Please check them for some explanation and suggestions.

    Report Viewer 2010, poor HTML rendering performance comparing to 2008

    http://social.msdn.microsoft.com/Forums/vi-VN/vsreportcontrols/thread/32bac505-8ea1-4a9b-8ab8-41911e0454e3

    ReportViewer local report 10 times slower than same report from Report Builder 2.0

    http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/770c24d3-8e48-4310-9459-04601d374958/

    ReportViewer Control in VB.NET application, System.OutOfMemory & General poor performance.

    http://social.msdn.microsoft.com/Forums/en-US/vsreportcontrols/thread/5b1b2348-5f9e-4c94-ad87-bc2cbabb6808/

     

    I move it to the dedicated Visual Studio Report Controls Forum for better support.

    Thanks for your understanding and active participation in MSDN Forum.

     


    Martin Xie [MSFT]
    MSDN Community Support | Feedback to us
    Monday, November 14, 2011 6:53 AM
  • Hi Martin,

     

    Thank you for moving my question to the dedicated forum (I did not find it in the MSDN links page...).

     

    As for the links you suggested, I searched intensively for many days the MSDN forums before posting this question, and did not found any useful tip about my issue.

    Adopting the Microsoft Reporting technologies in my project should be very important even in a strategic view since my customer is using a different tecnology for reporting and I would like to introduce this new "idea", at this step it should be only to supply an advanced "printing" feature, but there are good chances to extend the Microsoft Reporting technologies for other projects.

    Obviously I cannot delivery the solution with these performance issues.

    Could you kindly help me finding a solution?

     

    Thank you

    Alberto

     

    Tuesday, November 15, 2011 7:43 AM
  • Hi Alberto,

    If you can send me a project that can reproduce this problem with generic data, I can take a look at it for you and see if there is anything we can change to help out.

    Otherwise you might be best to contact Microsoft CSS for resolution or to file a bug at http://connect.microsoft.com for the Report Viewer Control.


    Brad Syputa, Microsoft Reporting Services This posting is provided "AS IS" with no warranties.
    Tuesday, November 15, 2011 8:49 PM
  • Hi Brad,

     

    Thanks for your reply. I will try to extract a lighter sample project (with dependencies on a smaller database schema).

    Can you send me the instruction on how to send you the project?

     

    Thank you very much for help

    Alberto

    Wednesday, November 16, 2011 8:56 AM
  • Hey Alberto, you can send the project to the following addresses or just attach the project to the bug you file in connect:

    bradsy@<remove me>.microsoft.com
    mmeyer@<remove me>.microsoft.com

    Also I have one quick question for you, what version of .NET are you seeing this issue on? Thanks!

    Matt M.
    --------------------------------------------------------------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights

    Wednesday, November 16, 2011 6:41 PM
  • Hi Matt,

    It appears I forgot to write in my first post the application is based on .Net Framework 4 with VS 2010 SP1.

    The Microsoft.ReportViewer.Common.dll and Microsoft.ReportViewer.WinForms.dll versions are 10.0.40219.329 (applied hotfix KB2549864 after SP1 last summer, as soon it was published on connect).

    I use Microsoft Reporting in many projects, and before, I never had any problem with it

     

    Now I am trying to "extract" a smaller version of the application (it may take a while).

     

    Thank you very much

    Alberto

    Thursday, November 17, 2011 3:05 PM
  • Can you try enabling the legacyCasPolicy switch in your app.config and see if that resolves the issue?

    <legacyCasPolicy enabled="true" />

    Matt M.
    --------------------------------------------------------------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights
    Thursday, November 17, 2011 8:37 PM
  • Hi Matt,

     

    Thank you for your reply and your idea, after your post I tried again with the legacy features, using both the

    <legacyCasPolicy enabled="true" /> and the <NetFx40_LegacySecurityPolicy enabled="true|false"/> settings in the app.config files of all the involved projects, but without success.

    Also tried the related obsolete methods to force the report to be executed in application appdomain since executing in sandbox domain is the default, (LocalReport.ExecuteReportInCurrentAppDomain) but I have always got Invalid Operation Exceptions even while using the configurations to enable the legacyCasPolicy.

    But your troubleshooting ideas and the work to extract a sample project to reproduce the issue gave me the hint to find the solution.

    It is not a ReportViewer bug.

     

    Solution:

     

    1. The report is bound to an object datasource: the datasource is a very simple class used only to pack the report data from the real source (a form with advanced dynamic binding to EF source). This class was exposing the object property for the "original" field value (the EF entity):

     

     Public Class ProductFieldInfo
            Public Property FieldValue As Object
            Public Property FieldLabel As String
            Public Property FieldsGroup As String
            Public Property ValueFormat As String
            Public Property ColumnIndex As Integer
            Public Property SortIndex As Integer
     
            Public ReadOnly Property StringValue As String
                Get
                    Return Me.GetStringValue
                End Get
            End Property
            Public Function GetStringValue() As String
                If IsNothing(_FieldValue) Then Return Nothing
     
                Dim res As String
     
                If String.IsNullOrEmpty(_ValueFormat) Then
                    res = _FieldValue.ToString
                Else
                    res = String.Format("{0:" & _ValueFormat & "}", _FieldValue)
                End If
     
                Return res
            End Function 
     
    

     

    2. In the report I do not use the FieldValue object, but only its string representation (StringValue).

    3. I found that - even if not used in the Report - the FieldValue property is evaluated. This is quite a strange behavior and I would suggest the Microsoft Reporting team to try to avoid it and evaluate only the properties used by the report to render.

    4. Since in the FieldValue field are stored many different objects (many different EF entities), the evaluation of this field was causing an enormous delay because of the interaction with the dataform previously loaded and populated with data from the same EF Entity Container instance: my idea is that all the relations involving the FieldValue values (EF entities) are loaded at "rendering time" for all the records displayed in the dataform: a huge work for the EF Tracking.

    5. The solution: I simply changed the FieldValue property to a private field to avoid the object to be processed.

            Private _FieldValue As Object
            Private _ValueFormat As String

    Now the EF entities are no more visible to the report, and the rendering time normal (a few seconds for the first and a while for the others).

     

    Hope my solution will help, if need more info let me know writing on this post or contacting me by mail.

     

    Many thanks to Matt and Brad for support

    Alberto

     

     

    • Proposed as answer by Matt Meyer - MSFT Friday, November 18, 2011 5:39 PM
    • Marked as answer by Piggy Saturday, November 19, 2011 10:34 AM
    Friday, November 18, 2011 11:40 AM