Image to XOD conversion performance

[Support]

Taken from PDFNet forum:

https://groups.google.com/d/msg/pdfnet-sdk/jMlSR_dM4II/Rx27iyZ8sb0J

Q:  We've started performance testing the PDF-oriented workflow outlined here (Best practice for converting multiple TIFF/JPG files to a single XOD), and we're seeing some performance problems.

For smaller image collections (<=100kb or so), we reliably get sub-second conversion times, which is what we want.  However, once documents are larger than this threshold, we start to see times measured in tens or hundreds of seconds, and would like to find a faster way.

Our environments tend to have spare processor power for jobs like this; is there any way we can parallelize the conversion process, or parts of it?  Alternately, do you have any performance numbers around other methods of conversion, such as converting single-page TIFF files to multi-page instead of PDF?

-----
A:

The performance would in large part depend on input files (i.e. the type of TIFF/JPEG) you are dealing with. For example, a single TIFF frame at 200 DPI could theoretically be 4x slower that processing 100 DPI file (since the number of pixels increases exponentially with resolution). Also the conversion speed may vary depending on the compression method (e.g. CCITTFax, JBIG, Flate, LZW, Flate, etc) and other factors.

 

> is there any way we can parallelize the conversion process, or parts of it

 

Technically this is possible. You could parallelize conversion from multiple images to PDF (then merge files together) or to XOD then merge pages, h

however the question arises whether this is really necessary.

 

Once XOD is converted, you should probably cache it to avoid having to convert every time someone want to view the same document. You could also convert to XOD as soon as the file is added to doc library instead of at the moment user requests the file for viewing. Finally rather than waiting for the file to completely convert you can also on-the-fly convert and stream partially converted file to WebViewer (for example see WebViewerStreaming sample that comes as part of PDFNet SDK). This is probably preferable to parallelizing conversion because a user may want to close the document soon after it is opened. Kepp in mind that for best viewing experience (that allows to instant jumping to page regardless of doc size) we recommend accessing pre-converted XOD files and HTTPPartRetriever (which supports HTTP Byte Ranges).