Improve Conversion Speeds

[oregonpillow]

What is the feature you think should be a good addition to Dangerzone?

I'm new to the project and only skimmed the code so far, but the conversion of PDF to bitmap pixels and OCR stand out to me as large potential bottlenecks for the slow conversion speeds I observed when running a large test PDF.

It looks like neither pixel conversion or OCR is multi-processed. On small docs, streaming to bitmap is fine, but on large documents (100+ pages) the streaming time could be improved considerably i think.

However, since OCR conversion is more demanding I think this would be the first candidate for optimizing. Was there a specific reason this wasn't previously implemented? Would you be open to this?

Is your feature request related to a problem? Please describe.

Slow conversion speeds

[almet]

Hi, and thanks for opening an issue. That's a good question!

Right now, what's happening is that the document is streamed to the stdin of a process inside the container, where then it's opened and converted to pixels which are sent back to the host using stdout.

Then, on the host, the PDF is reconstructed and OCR is optionally run on top.

It could be very interesting to do profiling to know where most of the time is spent.

If data-streaming takes longer than what we want, we might want to parallelize the streaming of pixels from the sandbox to the host. Right now it's sequential. We're currently using stdin and stdout to lower the attack surface of the container: it's not able to read files, or write files on the host, or connect to any network.

If OCR is the bottleneck, doing it in parallel might speed up things, as you mention. We're currently doing the OCR as we receive the data, and just after we reconstruct the PDF page. Don't hesitate if you want to give it a go!

With all that said, I think it would be interesting to have a profiling done (in the container and in the host) to see what are the current bottlenecks.

[apyrgio]

I agree with what Alexis said, and I wanted to add some extra observations:

1. There's some expected slowdown due to our isolation layers. On Windows and macOS, we need a Linux VM, so there's a virtualization slowedown. Then, on all platforms, there's gVisor involved, which incurs a performance penalty on system calls. Granted, this affects only the rasterization part, not the reconstruction part.
2. One of the reasons why we don't spawn multiple OCR threads, or convert multiple documents at the same time, is that the Tesseract library spawns multiple threads for OCR under the hood, and these threads use up all the CPU. So, while I do agree that OCR takes a while, I'm not sure if multi-threading is the way to make it faster. It could be that the models we are using are not the fastest, or that we need to tweak Tesseract some other way.