I am using the following code to open a presentation:
long start = new Date().getTime();
_presentation = new PresentationEx(fileName);
long end = new Date().getTime();
System.out.println("Took: " + (end - start) + “ms”);
On my Core i5 / 8 GB RAM Notebook with 64 Bit Java 7 SE Update 11 this outputs Took: 4282ms which is way too long. This is just an example of the overal bad performance. Saving to pptx or pdf as well as generating thumbnail images is just as bad or even worse.
The (empty) presentation referenced in fileName is attached. It is the empty default presentation of my german Powerpoint 2010.
Is there any way to improve performance by a huge margin, say at least 400%? Otherwise the library would not be usable for our purposes.
I can add some further investigation results:
I suspect the classloader is the problem. On the second execution of the same code within the same VM the performance rises by over 1000% to ~400 ms
Why does the library need to load over 3700 classes? This is extremely inefficient.
Hi Patrick,
Thanks for your interest in Aspose.Slides.
I have observed the inquiry shared by you and have been able to reproduce the scenario shared in your first post. Can you please kindly explain the scenario that you have mentioned in your in second post where by you have obtained improved performance. Kindly share the sample java file for further investigation in this regard.
I suspect the classloader is the problem. On the second execution of the same code within the same VM the performance rises by over 1000% to ~400 ms
Many Thanks,
Hi Mudassir,
the code of the second scenaro is:
long start = new Date().getTime();
PresentationEx presentation1 = new PresentationEx(fileName);
long end = new Date().getTime();
System.out.println("1st took: " + (end - start) + “ms”);
start = new Date().getTime();
PresentationEx presentation2 = new PresentationEx(fileName);
end = new Date().getTime();
System.out.println("2nd took: " + (end - start) + “ms”);
Displays on my device:
1st took: 4836ms
2nd took: 457ms
Hi Patrick,
I have observed the issue shared by you and have been able to reproduce it as well. Actually, the first iteration takes longer due to the fact that it has to load the classes in DOM. This is a performance issue and I have created an issue with ID SLIDESJAVA-33701 to further investigate it on our development team end. This thread has been linked with the issue so that you may be automatically notified once the issue will be resolved.
We are sorry for your inconvenience,
In addition the memory overhead is very large.
public static void main(String[] args) {
PresentationEx pres = new PresentationEx();
pres.write(“out.pptx”);
System.out.println(“Done”);
}
I profiled this code and around 200MB of heap space is used. Does this seem reasonable?
Hi Shaun,
I like to share that the 200MB heap size usage depends upon the number of slides insides presentation, the contents inside slide, if there are any multimedia objects inside slides. Actually, when the presentation is loaded inside Document Object model of Aspose.Slides the respective properties values gets set. Its not related to the fact that what is actual presentation size, it may take same amount in memory when loaded. I would still request you to please share the sample presentation with us and I will investigate the issue further on my end to help you out.
Many Thanks,
The code in my example was the actual code I used (did not open any file). The 200MB usage was observed just by creating a default PresentationEx instance and writing it to the file system.
Hi Shaun,
I have tried to reproduce the scenario shared by you on my end using Aspose.Slides for Java 6.9.1 and memory usage on my machine caped upto 74MB. For your kind reference, I have attached the snapshot highlighting the memory usage and code used.
Secondly, I also like to add that the growing memory may be related to SLIDESJAVA-33701. Actually, loading of all classes of Aspose.Slides for Java namespace in memory is probably related to it. When issue SLIDESJAVA-33701 will be resolved, I feel this issue will also be addressed. I will update the mentioned issue comments to consider this aspect as well.
We are also working on further optimization of our API and improving its performance. One of major milestone in terms of performance will be achieved when will share the product release with unified API for both PPT and PPTX (which are currently separate at the moment).This product is expected to be released during 2nd quarter of 2013.
Please share your feedback related to memory usage as I have not been able to observe 200 MB memory usage on my end. I am using 1.6Ghz Core I7 machine installed with Windows 7 x64 and 8 GB Ram. I am using JDK 1.6_27 on my end.
Many Thanks,
I have attached a screenshot from the profiler. Note that peak memory use was 238MB. I am using JDK 1.6.0_33.
I’m not sure how you measured your figure, but obviously the garbage collector will free memory at certain intervals, but I don’t think that detracts from the main point that 200+MB overhead seems a little bit excessive.
But I am very glad to hear that improvements and the unified API are on the way.
As a point of comparison, Aspose.Cells uses 35MB of heap memory running a similar test (creating an empty workbook and saving).
I realise you can’t directly compare the two products, but it’s a far more acceptable and workable overhead.
Hi Shaun,
Thanks for sharing the updates. I have updated the issue status with the information shared. We will share the further information with you as soon as the investigation will be carried by our development team and issue will be resolved.
Many Thanks,
The latest version still has huge memory and performance issues. It’s clear that your auto-port process is creating highly inefficient code.
When I profile the same code as before (creating an empty presentation and saving it to the file system) the memory use is 113MB which is an improvement over before, but still really high.
Among the objects created are 90,230 instances of com.aspose.slides.Collections.ArrayList with a retained size of 43MB. Can you perhaps explain why the library needs to create over 90,000 ArrayLists in an empty document and what they’re used for?
I find it hard to justify a baseline use of over 100MB for an empty report.
We want to put the Java version into production software in the near future but the memory/performance issues are making that very hard to do.
For example, I tested opening one of out typical documents (170 slides with charts, tables, images and other shapes). Memory use peaks at just under 1GB and it took nearly 2 minutes to parse and save. There are now over 2.2 million com.aspose.slides.Collections.ArrayList objects created.
Hi Shaun,
Thanks for sharing the further feedback. I like to share that we are working continually on improving the performance of Aspose.Slides and your issue is in progress at the moment. I have shared the feedback shared with our development team and as soon as the feedback will be shared by them, I will share the response with you.
Many Thanks,
The issues you have found earlier (filed as SLIDESJAVA-33701) have been fixed in this update.
This message was posted using Notification2Forum from Downloads module by Aspose Notifier.