xtrareports-405035-reporting-memory-usage.md
This help topic includes tips on memory usage optimization and explains how you can prevent common reporting-related memory consumption issues.
This topic describes three main issues related to memory consumption:
OutOfMemory exception is thrownDue to .NET specifics, all dependent assemblies are loaded to the application’s memory on demand. As a result, the first time you run a report in your application you may observe an increase in memory usage. This is expected behavior.
Recent versions (the latest minor build for the last three major versions) of DevExpress components can optimize performance and memory use compared to older releases.
The same relates to third-party libraries (for example, Skia) that may be required by our components on non-windows platforms.
How to reduce memory consumption:
The more pages a report document contains, the more memory is required to store this document.
How to reduce memory consumption:
Raster images loaded to XRPictureBox controls are stored in report documents as bitmaps. The larger the image’s dimensions, the more memory is consumed.
How to reduce memory consumption:
XRPictureBox controls.XRPictureBox control. A report can cache images with the same ImageUrl values if it uses the CachedReportSource component.The XRRichText control uses the functionality of DevExpress Word Processing Document API. For each individual control, the report creates a rich document model. This is a very resource-intensive operation. As a result, a report with XRRichText controls may consume lots of memory.
How to reduce memory consumption:
XRRichText controls with XRLabel controls. You can enable AllowMarkupText functionality in the XRLabel control to add simple formatting to text.The Web Document Viewer component and the Web Report Designer’s preview functionality use the in-memory cache to store previewed documents. As a result, the application usage may grow each time a report preview is executed in a web application, and the memory may not be released immediately after the preview is closed. Check the Document Viewer Lifecycle documentation for more details on how this works.
It is not possible to completely disable the in-memory cache while using these components due to architecture specifics.
Note
This behavior does not relate to Report Viewer for Blazor (Native) and is specific to JavaScript-Based Blazor Reporting controls.
How to reduce memory consumption:
Enable the UseCachedReportSourceBuilder mode.
Enable file system storage for the document preview control. In .NET 8+ applications, you can also use IDistributedCache as a storage.
Close the previewed document each time before the browser’s page is closed to release the previewed document immediately.
Use StorageCleanerSettings and CacheCleanerSettings services to configure document and report lifetimes in Document Viewer’s storage and in-memory cache.
All of these recommendations are demonstrated in the following code example: ASP.NET Core Reporting Best Practices.
If none of the recommendations listed above help and you wish to reduce your web application’s memory usage as much as possible, you can replace a Document Preview in your web application with an exported PDF document. For example, you can use the <embed> HTML tag. Check the following help topic to learn how to export a report to PDF in a web application: Export Without a Preview.
You can use an external Parameters Panel control to pass parameters to a report while using this solution.
In the server-side code, you can also use either CachedReportSource or PdfStreamingExporter components to generate a PDF document. These components allow you to try different export algorithms and choose which one is best for your particular report, according to your export performance and memory consumption requirements.
The following sections explain how to diagnose a possible memory leak.
Due to .NET application architecture specifics, an increase in memory usage does not always indicate a memory leak. In most cases, this is related to .NET garbage collection specifics.
To confirm a memory leak, check if the application’s memory is released after garbage collection.
To trigger garbage collection in your application, you can use .NET memory profiling tools or call the following code in your application:
GC.Collect();
GC.WaitForPendingFinalizers();
Proceed to the next step only if the memory is not cleared after several garbage collections.
Use .NET memory profiling tools to analyze your application’s memory usage.
The following example shows how you can diagnose a memory leak with a standard dotnet-gcdump tool. Similar steps can be used with any other .NET memory profiling tool.
Run the reporting application.
Open/preview a report in your application for the first time to load all dependencies and static resources.
Wait until the memory used by the report is released.
Collect the initial memory dump. For this, use the collect command available in dotnet-gcdump.
Replicate the memory leak issue. Follow the steps required to replicate a memory leak with your reports. For example, you can run the same report multiple times.
Wait until the memory used by reports is released (repeat step three).
Collect the final memory dump.
Compare collected memory dumps.
Review the following tutorials for more information on how to analyze an application’s memory usage with cloud services:
Analyze memory dumps by reviewing what types are leaking. If you see no DevExpress types in the list of leaking types, the issue is most likely not related to our components.
The general recommendation for this step is to review how problematic objects were created in your application, and then make sure that all of these objects are disposed of correctly in your code.
If you are sure that your code is correct, but you see leaking DevExpress objects in your application, report the memory leak to DevExpress Support.
The OutOfMemory exception indicates that there is not enough memory in your application to continue the code execution.
In most cases, this exception does not indicate bugs and memory leaks. The following solutions are available:
Reduce memory consumption.
Increase the amount of memory available for your application.
If none of these recommendations help, follow recommendations listed in the Analyze the Memory Usage section in this help topic to diagnose a possible memory leak.
Before you start, please follow the diagnostic steps described above to confirm the memory leak and to make sure that this leak is related to DevExpress components.
To report the issue, submit a new support ticket and specify the following information:
Platforms and frameworks.
Environment information.
DevExpress components information.
Steps to reproduce the issue in your application.
Share implementation details.
Attach information obtained after conducting memory usage diagnostics.