Java vs .NET Performance

Aspose.Slides Product Family
1

I and others have been reporting on the performance and memory consumption problems in the Java version for years now (I have posts dating back to 2013).


Can you provide a reason why there is such wildly different performance between the Java and .NET versions?

Take for example the attached presentation, time taken to create a Presentation object (using the current release).

Java code:

public static void main(String[] args) {
final Presentation p = new Presentation(“c:/export/Input.pptx”);
}

Time taken = 4.5 seconds,
Peak memory usage = 292MB

.NET code:

static void Main(string[] args)
{
IPresentation p = new Presentation(“c:/export/Input.pptx”);
}

Time taken = 1.5 seconds
Peak memory usage = 63MB


All I want to know is that Aspose.Slides Team is taking this issues seriously and is going to bring the Java version performance into line with the .NET version, in a reasonable amount of time.


2

Hi Shaun,


Thank you for posting.

I have observed your comments and like to share with you that it is a well known issue and in most cases it refers to Java restrictions. I request you to please share with us the results when,
a) code compilled without debug info
b) target platform is Oracle JDK 1.7 on Windows (same machine for .Net test)
c) JVM running with next keys:
-XX:CompileThreshold=1 -XX:+UseParallelGC -XX:+UseConcMarkSweepGC -XX:+AggressiveOpts
d) -Xmx options allocates enough memory
e) execution time calculated after jvm warm-up and GC.Collect

We expect better results after jvm warm-up for this case.

Please share requested data and information with us so that we may proceed further to help you out.
3

Have you tested this? I’d love to know how you are using -XX:+UseParallelGC and -XX:+UseConcMarkSweepGC at the same time.


Also you should never manually call a garbage collect. It is bad practice.
4

I repeated the experiment with 100 iterations for warm up and then 100 iterations for the test.


I did not use the JVM arguments you suggested.

.NET=Average of 522ms per iteration
Java=Average of 279ms per iteration.

So in this case the results show the Java version is nearly 2x faster. If you could repeat this test using the file I attached previously I would be interested to see if you have the same results.

5

Hi Shaun,


I have observed your comments and I agree with you that -XX:+UseParallelGC and -XX:+UseConcMarkSweepGC can not be used at same time, as well as the garbage collect should not be called manually, but we are calling the Garbage collector just to test things, because we need a perfectly clean environment so that we may calculate time for code execution only, not for warm-up, GC or any other parasitic action. Also, 100 iterations for warm up is just like -XX:CompileThreshold=1, but not exactly.

I have discussed this in detail, with our product team and I have logged an investigation ticket with ID, SLIDESJAVA-35179, in our issue management system, to take care of your concerns. We will get back to you with our findings soon. We appreciate your patience in this regard.

Best Regards,
6
Hi Shaun,

Thank you for being patient.

I would like to share with you that, our results for 100 iterations for warm up and then 100 iterations for the test, on a machine with specifications as Intel i7-2700K and 16GB RAM, are explained in the attached image (see results.JPG). We have tested the memory consumption, while using Aspose.Slides for .NET 16.1.0 and Aspose.Slides for Java 16.1.0. Java consumes ~ 280 MB while .NET consumes ~244 MB of memory. We have used dotMemory for .NET and jvisualvm for Java memory testing. Can you please explain how did you get 63 MB for .NET and 292 MB for Java.

Best Regards,
7
Hi,

can you explain why .NET is 2x and more slower than Java version. Any chance to accelerate .NET components?

Thanks,
Oliver
8

I used YourKit Java Profiler and the built in profiling tools for Visual Studio.


The library has improved enormously especially over the last 6 months but the memory usage is still too high for reasons that don’t make a lot of sense. Because Aspose obfuscate’s the code it is very hard to tell exactly what the objects are but when I inspect heap dumps I see hundreds of thousands of objects even in an empty report with one slide and no shapes. What exactly is all of this overhead?

My server application is required to handle PPTX files up to 300 slides. When we ran an old .NET version it was hosted on a server with 4GB RAM.

We are currently hosting the Java version on a server with 30GB RAM in order to avoid OutOfMemory exceptions. It’s a huge additional cost and it is preventing us from deploying the component in additional scenarios which we would like to do.
9

Hi Shaun,


I have observed your comments and like to request you to please share with us the presentation containing 300+ slides and the code that you are using for testing purpose so that we may investigate it further to help you out.

Best Regards,
10

Hi Shaun,


I would like to repeat the request for source file and the sample code which you are using on your end, so that we may investigate if you are still facing the problem or the issue may be closed otherwise.

Best Regards,
11

The data is confidential so I can’t share it. Recent versions have been a significant improvement and I have been able to reduce the heap size allocation to 15GB in the latest deployments. Close the case.

12

Hi Shaun,


Thank you for sharing your valuable feedback.

I have observed your comments and like to share with you that we are working to further improve the performance of Aspose.Slides. It is an iterative process and we hope for better performance in subsequent. We are closing this specific ticket as per the feedback shared by you.

Best Regards,
13

The issues you have found earlier (filed as SLIDESJAVA-35179) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by Aspose Notifier.