We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Memory usage issue in Apose API while creating Workbook object

Hi,

We are using Aspose Cellls java 8.6.1 and facing serious memory related issues while creating Workbook objects from the excel files.

As an example we have taken a excel file whose size is approx 18 MB. When we try to create a workbook object from this file, the jvm memory shoots upto 722 MB for the single document.

To reproduce the issue we executed a java program (attached here) which simply creates a Workbook object. To analyse the memory usage we used JConsole.
From the screenshots attached you can clearly observe the following:
- Before creating the Workbook object the jvm memory was around 49 MB
- During creation of Workbook object it peaked upto 722 MB

This analysis is of single document of 18 MB which requires around 700 MB of memory.
Since we have the Enterprise License where hundreds of users are accessing the System and making simultaneous request the memory usage goes beyond the practical limits. For example: if we calculate - for such 100 parallel requests it requires 70 GB of memory only to create Workbook objects.

Can you please look into this issue on urgent basis, as our customers are facing this in their production environments.

Thanks,
Neeraj

Hi,


Thanks for providing us template file, sample code and details.

Please try our latest version/fix: Aspose.Cells for Java v8.6.2:
http://www.aspose.com/community/files/72/java-components/aspose.cells-for-java/entry670755.aspx

we made enhancements regarding performance and memory management in it.

Well, your template file has 18.1 MB in size and MS Excel itself takes sometime to open into it due to diverse data and formulas used in different worksheets. Aspose.Cells, normally needs 10 times or more memory (of the size of the original file) to load the file into its object model, it is also not final considering the fact evaluating some complex spreadsheets (as your file is).

Thank you.

Hi,


Thanks for the update.

I have tried using Aspose Cells 8.6.2 as well but there does not seem to be any improvement with regards to the memory usage issue I have reported. Results are more or less the same.

Although, using memory 10 times the size of the document is also too much but in this case it is talking around 40 times to the size of the document.

As it is reported by the customers on their production environment, can you please look into this on priority?

Thanks,
Neeraj



Hi,


Thanks for providing further details.

It looks like an issue with memory usage in Apose.Cells.Workbook API while creating/opening Workbook object for your provided template file (18.1 MB). I think for your case, the memory goes a bit high than usual. We need to investigate your issue in details and we will check if we could improve the memory management in this case.
e.g
Sample code:

System.out.println(“Before constructing workbook object”);
Workbook workbook = new Workbook(“C:\temp\test.xlsx”);
System.out.println(“After constructing workbook object”);

I have logged an investigation ticket with an id “CELLSJAVA-41587” for your issue. Our product team will look into it soon.

Once we have any update on it, we will let you know here.

Thank you.

Hi,

Thanks for using Aspose.Cells.

We don’t think the memory shown in your screenshot is fully occupied
by cells model. We use following code to test the memory usage:

Java
System.out.println(CellsHelper.getVersion());
wb = new Workbook(“test.xlsx”);
Runtime rt = Runtime.getRuntime();
System.out.print((rt.totalMemory()-rt.freeMemory())+ “/” + rt.totalMemory());



With our latest version: Aspose.Cells for Java 8.6.2, we get the output as:


115865888/186056704

Here you can see the maximum memory allocated while loading the template
file is about 185M and after the loading process, memory used by cells
model is about 115M, much smaller than 700M.



And if we use memory_preference mode:

Java
LoadOptions opts = new LoadOptions();
opts.setMemorySetting(MemorySetting.MEMORY_PREFERENCE);

wb = new Workbook(“test.xlsx”, opts);



the output we got is:


69847472/111345664

Only 110M memory allocated for the loading process and no more than 70M memory used by cells model.

Hi,

Thanks for using Aspose.Cells.

And another notable thing for memory cost and template file size: 10 times memory of the template file size is for xls file.

For xlsx/xlsm/xlsb files, they are in fact in zip format, which makes their file size is much smaller than the xls files with same data. So for such kind of files, they may need more memory than xls if they have the same file size.

Hi,


Can you please try using JConsole (see screenshots attached in earlier) and observe the memory usage while the Workbook object is being created. Because the memory usage peaks to 700 MB while generating the Workbook object and in the next statement (i.e. after the workbook is generated) it lowers down. The memory usage observed by you using Runtime is after the Workbook object is created.

Thanks,
Neeraj

Hi,

Thanks for your feedback and using Aspose.Cells.

Please share some screenshots highlighting the issue so that we could look into your issue further. Thanks for your help and cooperation in investigating this issue.

I have already shared screenshots and the java file used for gauging the memory usage. You can see the first mail of this thread when I logged the issue.


Thanks,
Neeraj

Hi,

Thanks for your feedback and using Aspose.Cells.

We think, it is not a bug as we shared in the above posts. However, we have logged your comment in our database against this issue for investigation. We will look into it and let you know our further findings. Once there is some news for you, we will share it with you asap.

Hi Neeraj,

Thanks for using Aspose.Cells.

We have requested the product team to provided some update regarding this issue. We will update you in the coming week.

Hi,

Thanks for using Aspose.Cells.

Please see attached screenshots of
JConsole monitor for loading your template file, we could not find the
issue of high memory cost of 700M.