PaddleOCR is re-created for every page: unusable on large PDFs (cache the engine?)

[quevon24]

Thanks for the plugin! We tried it as the OCR text-layer engine for large PDFs (~1,300 pages) on a GPU worker and hit a few things worth sharing. The first is a blocker for big documents; the other two are smaller.

1. PaddleOCR is instantiated per page (blocker on large docs)

The plugin appears to build a fresh PaddleOCR(...) for every page rather than once per run. On multi-hundred/thousand-page PDFs this dominates runtime: the model load/warmup cost is paid on every page, and the logs show Creating model: (...) repeating for each one. On our ~1,300-page test it looked "stuck" and blew past our execution timeout.

Workaround we used: monkeypatch the engine so the PaddleOCR instance is built once and reused across pages. With jobs=1 (sequential pages) that is safe and takes the run from "unusable" to normal speed.

Suggested fix: cache the PaddleOCR instance (module- or engine-level, keyed by the options that affect construction) instead of constructing it inside the per-page path. Since ocrmypdf calls the engine once per page, a single reused instance is the big win.

2. No way to pass enable_mkldnn=False (oneDNN crash on CPU, paddle 3.1)

The engine constructs PaddleOCR(...) with fixed kwargs, so there's no way to set enable_mkldnn=False. On paddlepaddle 3.1's CPU path the PIR + oneDNN route crashes (ConvertPirAttribute2RuntimeAttribute not support ...). We had to monkeypatch PaddleOCR.__init__ to default enable_mkldnn=False.

Suggested fix: allow passing PaddleOCR kwargs through (or at least expose enable_mkldnn) so users can avoid the crash and tune the engine.

3. Hard dependency on CPU paddlepaddle clobbers paddlepaddle-gpu

The package declares a plain paddlepaddle (CPU) dependency. In an environment that already has paddlepaddle-gpu, a normal pip install ocrmypdf-paddleocr pulls CPU paddlepaddle over the GPU build, so paddle.is_compiled_with_cuda() becomes False, GPU acceleration is silently lost, and (see #2) the CPU oneDNN path then crashes. We had to install with --no-deps.

Suggestion: make paddlepaddle optional/looser, or document that GPU users should supply their own paddlepaddle/paddlepaddle-gpu and install the plugin with --no-deps.

Environment

• ocrmypdf-paddleocr @ git main; ocrmypdf 17.x; paddleocr 3.x; paddlepaddle(-gpu) 3.1
• GPU: NVIDIA RTX A4500 (CUDA 12.6); the oneDNN crash also reproduces on CPU
• Large PDFs (hundreds to ~1,300 pages)

Thanks again for putting this out there!