C1ReportViewer memory usage

Posted by: russell.foster on 10 October 2017, 5:58 am EST

  • Posted 10 October 2017, 5:58 am EST

    Does the C1ReportViewer control ever release memory after loading a document? If I run a memory diagnostic on the following code in a basic WPF application, I never see the C1ReportViewer objects destroyed (even when GC is forced). The PDF file that is loaded doesn’t seem to make any difference.

    
    public partial class MainWindow : Window
        {
            Button loadButton = new Button() { Content = "Load" };
            Button removeButton = new Button() { Content = "Remove" };
            StackPanel panel = new StackPanel();
            C1ReportViewer reportViewer;
    
            public MainWindow()
            {
                InitializeComponent();
    
                loadButton.Click += LoadButton_Click;
                removeButton.Click += RemoveButton_Click;
    
                panel.Children.Add(loadButton);
                panel.Children.Add(removeButton);
    
                rootGrid.Children.Add(panel);
            }
    
            private void LoadButton_Click(object sender, RoutedEventArgs e)
            {
                reportViewer = new C1ReportViewer();
    
                reportViewer.LoadDocument(@"c:\result.pdf");
    
                panel.Children.Add(reportViewer);
            }
    
            private void RemoveButton_Click(object sender, RoutedEventArgs e)
            {
                reportViewer.CloseDocument();
    
                panel.Children.Remove(reportViewer);
    
                reportViewer = null;
            }
        }
    
    
  • Posted 11 October 2017, 1:00 am EST

    Hi,

    I escalated this to concern team (TFS ID:290715 for internal use only). Will let you know as soon as there is any information from them.

    Thanks,

    Singh Sonu

  • Posted 13 October 2017, 12:12 am EST

    BTW, it looks as if the PDFViewer control has a similar issue.

    I’m attempting to workaround by creating an add in with the viewer control (https://docs.microsoft.com/en-us/dotnet/framework/wpf/app-development/wpf-add-ins-overview), so I can tear down the app domain and clean up the leak.

    This option does not work with the ReportViewer: it shows a blank document with the correct page count, even though it saves the document correctly. Very strange. The PDF viewer works a little better in this scenario, although it overall uses much more memory when zooming, etc.

  • Posted 16 October 2017, 2:48 pm EST

    Hi,

    Sorry to mention, but I could not understand your scenario from your last post.

    Can you share a sample application & steps to reproduce the issue for both (C1ReportViewer & C1PdfViewer) with us? So that we can ask from developer to look on the same.

    Thanks,

    Singh Sonu

  • Posted 17 October 2017, 12:09 am EST

    Hi Singh: The second scenario is pretty tightly integrated in our solution and based upon the WPF add-in model, which is a non-trivial and out of the ordinary use case, therefore I would not expect things to always work the way one would expect.

    As long as you fix the first case, I would be more than happy. Thanks!

  • Posted 17 October 2017, 2:05 am EST

    To be clear: the memory leak in the first scenario affects the PdfViewer control as well.

  • Posted 17 October 2017, 2:48 pm EST

    Hi,

    I escalated your issue to concern team for C1PdfViewer too. Will let you know as soon as there is any information from them.

    Thanks,

    Singh

  • Posted 23 October 2017, 10:01 pm EST

    Hi,

    I don’t see memory leak here. Garbage Collection doesn’t clear all memory immediately. Some objects might remove in memory if application doesn’t need new memory allocations. If I load/remove PdfViewer with attached application many time, say 20, I don’t see any grow in memory usage. And if I look at heap state after that, then I only see some object from the last instance of PdfViewer, so apparently all previous instances got removed successfully. When there is a memory leak, after 20 runs you should see 20 PdfViewer object on memory heap. So I think there is no real leak here.

    Thanks,

    Singh

  • Posted 6 November 2017, 6:13 am EST

    Are you seeing the leak in the ReportViewer? I can go back and re-test the PdfViewer to be sure, but I definitely saw the leak in ReportViewer. I saw two types of leaks, what was definitely a managed leak and possibly a native leak. Maybe I mixed up the two on the PdfViewer, but I am pretty certain I saw the managed one on ReportViewer.

    I tested using the Performance Profile in VS 2015, so I know garbage collection was being performed.

  • Posted 7 November 2017, 1:01 am EST

    ReportViewer leak should be fixed in upcoming v3 release. You can try it now, the build is already published here: http://prerelease.componentone.com/dotnet40/c1wpflibrary/2017-t3/C1WPFBasicLibrary.4_4.0.20173.578.zip

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels