Tools to test loading/rendering speed for different versions of same pdf?

Question

I would like some way to test pdf loading and rendering speed.

My ideal tool would let me drag and drop a batch of pdfs processed using ghostscript or sometimes k2opt, and compare some useful figure, such as the processor time or the memory usage to render the 1st page, or the 1st 10 pages, which would help me decide whether to go with k2opt instead of ghostscript. Or to try another processing option.

Background:

I am using MacOS 10.14.5 on a Mac Mini, and am using a Kindle Dx. Many newer pdfs will not load on the Kindle Dx, or will lose certain images, or will lose all page images.

I currently use a combination of ghostscript, Willus's k2opt, and ocrmypdf to pre-process pdfs for the Kindle, which also tends to speed loading on the Mac.

For pdf-born-pdfs with good text: I use ghostscript, to print to pdf, with compatibility levels 1.4. I run this in Automator and can't recall the full code with standard syntax.

For scanned pdfs with good text: I use k2opt -mode copy -dev dx. I usually run this in Automator.

For any pdfs with bad text: I either run k2opt -mode copy -dev dx or just k2opt -mode copy, and then take the result and run ocrmypdf -f --output-type pdfa-1 on it. I have not been able to run this in Automator, probably due to sandbox issues.

I previously experimented with using Ghostscript's compression settings, but these sometimes expanded pages so only the lower left corner was on-page. So I no longer use these settings.

These fixes usually solve compatibility problems and help with loading time problems, but a lot of the Ghostscript results still have excessive loading times.

I tried adding -dFastWebView but it did not help.

I often end up using k2opt, and rasterizing everything, simply to open files at a reasonable speed.

Any suggestions?

Thanks!

Answer 1

You can time the load & render times for your PDFs by installing wxPython, PyMuPDF & the wxPython demo.

To get started:

• From the command prompt: pip install -U wxPython PyMuPDF and wait until finished I initially tried this with PyPDF2 but had problems with many of the PDF files that I tried this may be different for you.
• From the command prompt run: wxdemo and accept the default location this will download the demo for your version of wxPython, unpack it and start it.
• In the demo window click into the search box and type pdf then select PDFViewer in the tree above:
• Click on the Demo Code tab and scroll down to the __init__ method
• Add a line to set self.log = log
• Scroll down to the OnLoadButton method

- Edit it to read:

    def OnLoadButton(self, event):
        self.log.write('Load PDF')
        dlg = wx.FileDialog(self, wildcard="*.pdf")
        if dlg.ShowModal() == wx.ID_OK:
            wx.BeginBusyCursor()
            start = time.time_ns()  # Requires python >3.7
            fname = dlg.GetPath()
            self.viewer.LoadFile(fname)
            end = time.time_ns()  # Requires python >3.7
            took = end-start
            msg = '{} Took {:n} nsec'.format(fname, took)
            print(msg)
            self.log.write(msg)
            wx.EndBusyCursor()
        dlg.Destroy()

- Save your changes by clicking on the save button then switch to the demo tab and try loading some pdf files.

This should give you some indication of the relative times to load & render different PDF files. If you are running a python < 3.7 so don't have time.time_ns available you can use time.time with less precision. You could even write the output to a file.

All of the above are free and open source.

Disclaimer - I was the original author of the wxdemo utility so am slightly plugging my own work - I get no financial benefit from its use.

Answer 2

I found another solution on the 24th using gtime -p -o input.pdf-timed.txt gs -dNOPAUSE -dQUIET -dBATCH input.pdf and using Automator for batch processing.

This yields a small txt file listing the time it takes for Ghostscript to run through the pdf file.

This requires gnu-time and ghostscript.

Be very careful to give a different filename for the output, otherwise it can overwrite the input.