Aspose-pdf.net - Conversion process speed

Aspose.PDF Product Family
1

Hi,

When using the 22.8 version of Aspose.Pdf, we’re seeing render times to jpg of around 2.5s. We’ve tried using the Aspose.Pdf Document class to do the extraction and also the Facades.PdfConverter, both show a similar performance.

We’ve ran this in netcoreapp3.1 and in .net6.0.

Have we missed something in terms of a performance issue or is there something else we can add in to speed it up?

Attached is the pdf.file.pdf (1.8 MB)

Sample code:
// Aspose.Pdf

  Document document = new Document(option.FileName);

  Resolution resolution = new Resolution(150, 150);

  JpegDevice jpegDevice = new JpegDevice(resolution, 85);

  using FileStream imageStream = File.Open(option.Output, FileMode.Create, FileAccess.Write, FileShare.None);

  jpegDevice.Process(document.Pages[option.Page], imageStream);

  imageStream.Close();
  document.Dispose();

  // Pdf Converter
  PdfConverter pdfConverter = new PdfConverter();

  pdfConverter.BindPdf(option.FileName);

  pdfConverter.DoConvert();
  pdfConverter.CoordinateType = PageCoordinateType.CropBox;
  pdfConverter.Resolution = new Resolution(150,150);
  pdfConverter.StartPage = option.Page;
  pdfConverter.EndPage = option.Page;
  pdfConverter.FormPresentationMode = FormPresentationMode.Production;

  while(pdfConverter.HasNextImage())
  {
    pdfConverter.GetNextImage(option.Output, System.Drawing.Imaging.ImageFormat.Jpeg);
  }

  pdfConverter.Close();

Any help would be appreciated

2

@simon.cooper

The speed or performance of the API is often calculated on the basis of subsequent runs. At the time of first run, API loads required resources into Memory like fonts that is why it takes some time. Once all resources are already present in the memory, the performance is better on subsequent runs. Could you please share if you are experiencing similar conversion time on subsequent runs as well?

3

Yes, on a second run, we do see a performance gain, the same test ran above ran in 2.5s for the first hit, and then 1s for the subsequent run.

If we are to pre-warm the conversion to get the performance out of it, can you tell us which objects we should keep as singletons if we want to maintain that performance?

Is it the JpegDevice or something within Aspose.Pdf that we don’t need to worry about?

4

@simon.cooper

There is no such thing to worry about as it is internal functionality of Aspose.PDF to load required resources. However, you can try to initialize fonts before executing the conversion related code in order to speed up the process:

FontRepository.LoadFonts();
5

Thanks, that interesting to note.

Can we have multiple instances of the conversion process running? e.g. if we opened the app 10 times, could we process 10 files at the same time, or does the conversion process use a singleton internally so they queue up?

6

@simon.cooper

The Aspose.PDF is a multithreaded safe API as long as one thread is accessing one document at the time. Regarding your question, we need to further check related details. Meanwhile, you can please try to test the scenario using this approach and let us know in case you face any issues.

7

@simon.cooper

Yes, if you create 10 instances of the document you can convert multiple documents at the same time. API uses shared fonts but all these shared resources are thread safe. Main thing, we can’t use single instance in multiple threads, every instance should be used in single thread.

8

Thanks, that’s good to know, we’re currently testing this out using the FontRepository.Load() and a max of 10 concurrent applications processing pdfs without unloading the app pool, see if that yields some performance gains.

We’re seeing conversion times for a single page at ~3s, which isn’t great, but hopefully once we’ve ran this for a while it will come down.

Are there any plans for performance fixes further down the line?

9

@simon.cooper

We improve API performance in every monthly release that is why we always recommend using the latest available version. We will surely be improving the API performance in future. However, if you have certain cases to share, please do so that we can log issues in our issue tracking system. This way you will be able to track progress against it.

10

Thanks Asad,
You’ve been really helpful in getting us going with this.

I do have one case to share, it is a simple file by the looks, but takes over 3.4s to convert to jpg. This is a dummy file we’ve generated from our system.
file1.pdf (504.7 KB)

I tested this against the new release of Aspose.Pdf 22.9 using the Facades namespace and the PdfConverter class.

Can you test a conversion of Pdf to jpg on this file, using Resolution(150,150) and seeing what sort of speed you see?

I’d be interested in knowing if you see a similar time to convert

11

@simon.cooper

We tested in a console application and best time for the conversion we got was 6 seconds. Off course, there were other test cases in the application as well. Also, the RAM size of the system was 8GB and OS was Windows 10 x64. Do you want to reduce conversion time more than 3.4s? Can you please share your environment details for our reference?

12

Hi Asad,
Yeah, we really do want it below 2 seconds, waiting 3+ seconds is an unacceptable user experience and a degradation of the performance we get with other tools, which we’re using Aspose.Pdf to replace.

I got the 3.4s raster time from a warmed instance on my local machine, which is specced out below

Processor: Intel® Core™ i7-7700HQ CPU @ 2.80GHz 2.80 GHz
Installed RAM: 16.0 GB (15.9 GB usable)
Product ID: Windows 10
System type: 64-bit operating system, x64-based processor
Pen and touch: Touch support with 10 touch points

I’m going to switch away from Aspose.Pdf for this purpose for now and move onto a different tool which gives us better performance, I’ll keep checking in on the release notes to see if there are other performance related fixes that we can re-evaluate the product in this usage with

13

@simon.cooper

We have logged an issue as PDFNET-52598 in our issue tracking system to further analyze this case. We will surely investigate it in details and as soon as the performance of the API is increased and ticket is resolved, you will be notified via this forum thread.

We really apologize for the inconvenience caused.