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

Free Support Forum - aspose.com

ASPOSE.SLIDES for JAVA 15.11.0 is consuming much more memory than expected when slide number goes up

Hi,

Currently we are using aspose.slides-15.11.0 to process PowerPoint files. We have 4G RAM and 2 CPU.
But always get memory usage problem while dealing with large PPT files. When slide number goes up, memory usage keep rising ,almost consume all the memory, then CPU usage reach the top.

In order to investigate further, we use simple java code to reproduce the problem (both java 1.7 and 1.8).

package com;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;

import com.aspose.slides.ISlide;
import com.aspose.slides.License;
import com.aspose.slides.Presentation;
import com.aspose.slides.SaveFormat;

public class TestPPT
{
public static void main(String[] args) throws FileNotFoundException
{
License license = new License();
license.setLicense("/home/vincent/licenses/Aspose.Total.Java.lic");

     File templateFolder = new File("src/main/resources/test");
     if (!templateFolder.isDirectory())
     {
         System.out.println("Not a folder");
         System.exit(1);
     }

     TestPPT test = new TestPPT();

     test.processDocuments(templateFolder, 50);
    System.exit(0);
}

public void processDocuments(File folder, int passes) throws FileNotFoundException
{
    Presentation presentation = null;
    int presentationNumber = 0;
    int slideNumber = 0;
    String path = folder.getAbsolutePath();
    String tempPath = path + "/temp/";

    for (int i = 0; i < passes; i++)
    {
        System.out.println("\nPass number " + (i < 10 ? "0" + i : i));
        for (File templateFile : folder.listFiles())
        {
            if (templateFile.isDirectory())
            {
                continue;
            }
            System.out.println("\t# Processing template " + templateFile.getName());
            if (presentation != null)
            {
                for (ISlide slide : (new Presentation(new FileInputStream(templateFile))).getSlides())
                {
                    slideNumber++;
                    System.out.println("\t\t# Processing slides: " + (slideNumber < 10 ? "00" + slideNumber : slideNumber < 100 ? slideNumber : slideNumber));
                    presentation.getSlides().addClone(slide);
                }
            }
            else
            {
                presentation = new Presentation(new FileInputStream(templateFile));
                slideNumber = presentation.getSlides().size();
            }
        }
        if (((i + 1) % 10) == 0)
        {
            File tempFolder = new File(tempPath);
            if (!tempFolder.exists())
            {
                tempFolder.mkdirs();
            }
            presentationNumber++;
            presentation.save(tempPath + "Presentation" + (presentationNumber < 10 ? "0" + presentationNumber : presentationNumber) + ".ppt", SaveFormat.Ppt);
            presentation.dispose();
            presentation = null;
            System.gc();
        }
    }
    if (presentationNumber == 0)
    {
        presentation.save(path + "Presentation.ppt", SaveFormat.Ppt);
        presentation.dispose();
        return;
    }
    else if (presentation != null)
    {
        presentation.save(tempPath + "Presentation" + (presentationNumber < 10 ? "0" + presentationNumber : presentationNumber) + ".ppt", SaveFormat.Ppt);
        presentation.dispose();
    }
    processDocuments(new File(tempPath), 1);
    return;
}

}



We tried run this test to gets all the files in that folder and joins them together to increase the size of the PPT. Iteration of the code tries to first save the presentations after 10 passes in another folder and then join them together instead of doing everything at once. This was an attempt to see if the problem was the number of files we were putting together or the actual size of the PPT. We saw no significant change between both.
(comment the if (((i + 1) % 10) == 0) block and the second call to processDocuments - processDocuments(new File(tempPath), 1); will do everything all at once)

In our test, we the slide number goes up to 1460, this java program takes 3.9G RAM and 198.7% CPU. and hanging there. We have no choice but to kill this java progress to get our resource back.

# Processing slides: 1456
# Processing template template (20).ppt
# Processing slides: 1457
# Processing slides: 1458
# Processing slides: 1459
# Processing slides: 1460
# Processing template template (39).ppt


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23105 vincent 20 0 3329m 3.9g 17m R 188.0 30.6 127:26.47 java

Is there any solution to solve this problem or improve the performance ? Or is it fixed already ?
Please take a look at this issue, and kindly look into this as soon as possible.

Hi Vincent,


Thank you for your interest in Aspose.Slides.

I have observed your comments and like to share with you that, I have tested it on my end and I am seeing better memory consumption while using Aspose.Slides for Java 16.1.0. I have tested it until 750 slides (see attached image) and not very huge memory consumption is noticed. Actually, the memory consumption depends on the source file, if it includes media content like audio, video or image then it consumes more memory, comparatively. I request you to please try using Aspose.Slides for Java 16.1.0 and then share your kind feedback with us. If the issue persists then please share with us Operating System details on your end, so that we may proceed further to help you out.

Best Regards,
Hi,

Thank you for your reply.

I've tested Aspose.Slides for Java 16.1.0 as you recommended. But i am afraid this issue still exist.

We use Aspose.Slide to generate a large PPT file (about 2000 slides). And, of course, parts of slides contain images. The final PPT file is about 70M.
But it would make the server crash each time since memory and CUP consumption problem.

As you mentioned, slides number goes up to 750, not very huge memory consumption found. We don't have huge memory consumption issue either when slides number reached 750.

But the time used to deal with each page is getting much more longer.
At the beginning, it can deal with several slide in each seconds. But when the slide number goes up to 1000+, especially 1200+, it will take several seconds to process a single slide. It is getting more and more slowly until hanging there.

But we don't have this issue by using aspose.slides-2.5.0.jar until we upgrade to Aspose.Slides for Java 15.11.0

Operating System details list below: ( CentOS release 6.7, 4G RAM, 2CPU)

$uname -a
Linux 2.6.32-573.3.1.el6.x86_64 #1 SMP Thu Aug 13 22:55:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$head -n 1 /etc/issue
CentOS release 6.7 (Final)


$cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version (cpu64-rhel6)
stepping : 3
microcode : 1
cpu MHz : 2400.084
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm unfair_spinlock pni cx16 hypervisor lahf_lm
bogomips : 4800.16
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version (cpu64-rhel6)
stepping : 3
microcode : 1
cpu MHz : 2400.084
cache size : 4096 KB
physical id : 1
siblings : 1
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm unfair_spinlock pni cx16 hypervisor lahf_lm
bogomips : 4800.16
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:


$grep MemTotal /proc/meminfo
MemTotal: 4054660 kB


May this information help us proceed further together to find a better solution or figure out how much Memory do we required.


Cheers
Vincent

Hi Vincent,


I have observed your comments and like to share with you that a ticket with ID SLIDESJAVA-35276 has been logged into our issue management system for further investigation and resolution of the issue. We will get back to you, if necessary, or we will share the notification with you as soon as the issue will be fixed.

We are sorry for your inconvenience,