Memory leak in aspose.words .net while running in linux

Hi Team,

In the attached sample app, we have two problems.

Problem 1) When the app starts, we are waiting for 1 min at the time memory usage is 30 MB, then we will start aspose word opration when memory increase up to 180 MB after completing aspose operation ideally it should come back to 30 MB which was expected. But even after all the operation is finished it stays in 160 MB forever. And the amount of memory getting stuck is different for different documents.

This problem happens for var asposeDoc = new Aspose.Words.Document("App/test21.docx"); this line itself we have commented out all other things except constructor still the memory leak is there in somewhere aspose constructor. If aspose preserving some constant memory to speed up the process it should be constant for all the document but in our case the amount of memory getting stuck diffrent for diffrent document. So, we wanted to know why some memory is not getting collected automatically and what is kept staying in that memory.

Please find the memory graph attached for your reference.

Problem 2) asposeDoc.Save(memoryStream, SaveFormat.Docx); The code saving document to stream takes around 8 sec for first time, but we wanted to reduce this up to 3 sec. So could you please suggest to us if there is any better way to do this to get better performance.

Please find the below logs

2024-03-15 19:55:36 Aspose cons = 2705.1317
2024-03-15 19:55:37 Reporting engine = 202.0302
**2024-03-15 19:55:47 Save to Memory stream = 9898.6231**
2024-03-15 19:55:47 Memory stream to byte array = 408.7583
2024-03-15 19:55:47 Total = 13214.5433
2024-03-15 19:55:48 Aspose cons = 919.7912
2024-03-15 19:55:48 Reporting engine = 0.8165
**2024-03-15 19:55:52 Save to Memory stream = 4353.7391**
2024-03-15 19:55:52 Memory stream to byte array = 16.0216
2024-03-15 19:55:52 Total = 5290.3684

It is a simple app, just run docker compose up in root folder(App copy- Aspose ticket).

Please find the app here
App copy- Aspose ticket.zip (639.5 KB)

It is a simple app, just run docker compose up in root folder of the app(App copy- Aspose ticket). Before running docker compose up please add these two files in root folder of the app(App copy- Aspose ticket)

File 1)
test.docx (2.7 MB)

File 2) This is another document too big to upload here. So, added it in google drive. Let me know once you download it.
https://docs.google.com/document/d/1iYtth5DV6JQ0BOZPDRQjF2e93wL-iPXq/edit?usp=drive_link&ouid=117240311428273177624&rtpof=true&sd=true

@sarathisathish90

  1. The document shared via google drive is not accessible. But there should note be any memory leak. Aspose.Words does not block any memory. But in Aspose.Words we use static fields to cache some information like styles, fonts, internal primitives. This behavior allows to improve performance of our library.
    Static fields persist for the life of the app domain or the process. GC.Collect doesn’t collect such fields.

  2. On the first call Aspose.Words inits static resources, such as fonts, which are then reused on the subsequent calls. You can create an empty document and save it as PDF, for example, on your application start to force Aspose.Words to init resources to avoid “cold” start on the real requests.

Try this link and let me know.

https://docs.google.com/document/d/1iYtth5DV6JQ0BOZPDRQjF2e93wL-iPXq/edit?usp=sharing&ouid=117240311428273177624&rtpof=true&sd=true

If Aspose.Words not releasing memory for static fields to cache some information like styles, fonts, internal primitives. The size should be the same for all cases.

But in our testing what we found is,

if we use only attached test12.docx throughout the process the unreleased size is around 160 MB
if we use only attached test.docx throughout the process the unreleased size is just 50 MB. Why is that?

@sarathisathish90 Thank you for additional information. Yes, now the document is accessible. But it still does not look like memory leak, since the amount of allocated memory does not grow if increase number of iterations. For different documents, different static resources initiation might be required that is why you see the difference.

This is problem for us.

Our actual use case not working with same document multiple times.

Our use case is we need to work with many big documents which may use different styles and fonts. For every big documents if it kept holding 100 MB that is problem for us.

Is there any way to clean up those memories as soon as we completed work for a document ?

@sarathisathish90 We will deeper investigate the issue and provide you more information.

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSNET-26745

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

Hi Team,

I appreciate that. If we get a solution back as soon as possible it will be better. We will create new tickets in the paid support service portal by mentioning this ticket number.

@alexey.noskov do you have any comment for my 2nd question.

Problem 2) asposeDoc.Save(memoryStream, SaveFormat.Docx); The code saving 30 MB document to stream takes around 8 sec for first time, but we wanted to reduce this up to 3 sec. So could you please suggest to us if there is any better way to do this to get better performance.

Thanks,
Sathish Govindan

@sarathisathish90

  1. Sure we will keep you updated regarding the issue.

  2. If the delay occurs only on the first save operation, then as I have mentioned in the first answer, you can “warm up” Aspose.Words by creating and saving a small document as PDF to make Aspose.Words to init all static resources.

@sarathisathish90 We have completed analyzing the issue and decided to close it as Not a Bug. We tested your sample with 30 iterations and have got the results:


There is only about 3MB managed memory allocated after the method finished and memory collected.

Hi @alexey.noskov ,

Could you please test the app with 30 different document which is diffrent in size from 10 MB to 30 MB

Thanks,
Sathish Govindan

@sarathisathish90 I have forwarded your request to our development team.

@sarathisathish90 We have tested the sample project on all docx files from our test data from 10MB to 165MB size with the next result:

@alexey.noskov Could you please test with document which I shared

@sarathisathish90 We have tested with your documents with the similar result.