QiqqaOCR: The Sorax PDF render library seems to take longer and longer, the higher the page number to render is.

[GerHobbelt]

The Sorax PDF render library seems to take longer and longer, the higher the page number to render in the PDF is.

Smells like we're facing a O(n^2) bad performance behaviour here, thanks to the way QiqqaOCR is working? (one page per invocation in SINGLE mode, which results in Sorax' apparent O(n) cost turning into O(1/2 n^2) thus O(n^2) performance hog at the Qiqqa level.

Would Sorax render costs drop when we simply grab all pages in the PDF at once and dump them to image files, to be Tesseract-OCR'd in another process?

[GerHobbelt]

See also #135 comments: check the commandline parameters listed there.

Local dev machine sample test commandline for QiqqaOCR to observe this behaviour:

SINGLE "D:\Qiqqa\base\INTRANET_EF52564A-831D-42F2-B956-815CF0418C08\documents\9\90336D7E2FC44F01BE9A53E58CEB9E60B8A85.pdf" 1-100 "C:\Users\Ger\AppData\Local\Temp\\TempFile.4cb114d4-3461-4844-8345-e710bf1cb62b.txt" "" "" NOKILL

Note the page range in that commandline: this is available for debugging QiqqaOCR since commit SHA-1: a758657

[GerHobbelt]

Won't fix this one.

I'm rather more intent on kicking out Sorax and going with MuPDF (and MuPDFSharp) as that's open source instead of closed source, so easier to dive in and debug. Sorax, as far as I am concerned, is a dead end that's needed until I have plugged in MuPDF for page rendering.

Regarding slow speed problems of MuPDF: those are different, but do exist: https://bugs.ghostscript.com/show_bug.cgi?id=701945#c2