High CPU Usage After Adopting Your .NET Library

GroupDocs.Conversion Product Family
,
1

Hey,

After integrating your library, we’ve observed a significant increase in CPU usage across our services.

Previously, we were using another vendor’s solution — it handled .docx files well but not PDFs. We switched to your library to improve PDF support, but initially encountered out-of-memory (OOM) errors, so we stopped using it for PDFs.

However, even when using it only for .docx files, we’re now experiencing a major spike in CPU consumption since the adoption.
image.png (17.7 ק״ב)

2

@Shay_BH

It sounds like you’re experiencing performance issues after integrating our .NET library, particularly with increased CPU usage when processing .docx files. Here are a few suggestions to help optimize performance:

  1. Performance Optimization: Review the performance optimization guidelines available for our library. These guidelines can help you balance recognition speed, quality, and resource usage effectively.

  2. Resource Management: Ensure that your application is managing resources efficiently. This includes limiting the number of threads used during processing and optimizing any image preprocessing filters if applicable.

  3. Batch Processing: If you’re processing multiple documents, consider implementing batch processing to reduce overhead and improve efficiency.

  4. Monitoring and Profiling: Use profiling tools to monitor CPU usage and identify any bottlenecks in your application. This can help you pinpoint specific areas that may need optimization.

If you continue to face issues, please provide more details about your implementation, and we can assist you further.

3

Hello @Shay_BH ,

Thank you for contacting us. Since this matter is a continuation of our previous discussion in this forum thread , we have conducted a preliminary comparison of memory usage between the previous version of GroupDocs.Conversion for .NET 25.8.0 and the latest 25.9.0. The results are shown below.

Version 25.8.0
• Conversion completed in 31m 21s
• Memory usage (see 25.8.0.png): memory is constantly increasing, reaching 8GB RAM

Version 25.9.0
• Conversion completed in 7m 45s
• Memory usage (see 25.9.0.png): memory stays around 1.3–1.5GB, with one small peak over 2GB

25.8.0.png (25.9 KB)
25.9.0.png (23.3 KB)

We have also attached a test project that converts a PDF file to MD — the same 2000-page document that you originally shared with us.

As you can see from the comparison, memory usage has been significantly reduced in the new version. Therefore, to continue our analysis based on your data, we will need some additional information from you:

  • the environment in which the conversion is being performed,
  • a more detailed screenshot of the memory usage graph,
  • and a small sample of your project.
    It’s possible that the consumption may be related to the way GroupDocs.Conversion is being used in your implementation.
4

we will provide that, regarding CPU what do you need from us for that?

5

@Shay_BH ,

We have already listed some points earlier, but regarding memory usage specifically, please also provide the following:

  • Screenshots, for example, from Task Manager, PerfMon, Docker Stats, or Azure Monitor (the graph image you shared earlier was cropped at the top, so we couldn’t see the full picture);
  • Peak RAM usage;
  • If available — a memory dump (.dmp) or a snapshot from dotMemory / PerfView;
  • How memory behaves after the tasks are completed (does it grow? is it not being released?).
6

adding here some memory inrofmation regarding excel file parsing.
i have a file that is 184 kB. i used your converter on this simple file and inspected the memory.
i saw an increase of 100MB in memory after converting the file, and when the process ended the memory wasnt freed.
adding a screenshot regarding this.
before converting
image.png (32.2 ק״ב)

after converting, and way after the process who used the data ended
image.png (24.3 ק״ב)

file_example_XLSX_5000.xlsx.zip (96.3 ק״ב)

7

when handling files that are 80MB this is the memory increase graph
from 200MB to 2.5GB and not freed.
image.png (35.4 ק״ב)

8

Hello @Shay_BH ,

Thank you for providing the sample file and the additional information — I will forward everything to our development team. However, to ensure that we can accurately reproduce the issue on our side, please also share the exact conversion code you are currently using.

9 
private static async Task<FileParserResult> ParseDocumentAsync(Stream fileStream, CancellationToken cancellationToken)
        {
            var convertOptions = new SpreadsheetConvertOptions { Format = SpreadsheetFileType.Csv };
            if (fileStream.Length == 0)
            {
                return FileParserResult.Empty;
            }

            var seekableStream = await fileStream.ResetPositionAsync(cancellationToken);

            var outputStream = new MemoryStream();

            try
            {
                var converter = new Converter(() => seekableStream);

                try
                {
                    converter.Convert((SaveContext _) => outputStream, convertOptions, cancellationToken);
                }
                catch (PasswordRequiredException)
                {
                    throw new NonRetryableOperationException("Document file is password protected");
                }

                var outputBytes = outputStream.ToArray();
                converter.Dispose();

                var content = System.Text.Encoding.UTF8.GetString(outputBytes);

                return new FileParserResult(content, Empty<FileParserResultImage>());
            }
            finally
            {
                await outputStream.DisposeAsync();
            }
        }
10

Hello @Shay_BH ,

Thank you for providing the code sample. I have passed all this information to our development team and created a corresponding ticket in our tracking system under the ID CONVERSIONNET-8087. As soon as I receive any updates from them, I will inform you right away.

11

Hello @Shay_BH ,

Our development team attempted to reproduce and analyze the behavior you described, but they were unable to confirm any memory not being released after each conversion.
They created a sample project (attached) that converts XLSX to CSV and ran it for 2,000 iterations to simulate a heavy load. During the test, memory consumption remained stable at around 220 MB, with approximately 200 MB attributed to unmanaged memory.
This unmanaged portion is the baseline amount that GroupDocs.Conversion allocates for its internal buffers and native resources—this is expected behavior, and the memory is reused between conversions rather than accumulated.
They tested this with versions 25.9 and 25.10, and the results were identical. Screenshots demonstrating the memory behavior in both versions are attached below.
XlsxToCsvResources.zip (102.7 KB)
profile-25.9.png (230.7 KB)
profile-25.10.png (218.2 KB)

Could you please re-check this sample in your environment and share your results?