The headline numbers#
Measured by docling.org with Docling 2.143.1. Lower is better.
Show data table
| s/page | |
|---|---|
| Default (OCR auto + tables) | 8.51 s |
| OCR off | 2.31 s |
| OCR off + fast tables | 2.05 s |
| OCR off + no table model | 1.59 s |
| Configuration | CLI flags | Median, 9 pages | Per page |
|---|---|---|---|
| Default | — | 76.6 s | 8.51 s |
| OCR off | --no-ocr | 20.8 s | 2.31 s |
| OCR off + fast tables | --no-ocr --table-mode fast | 18.4 s | 2.05 s |
| OCR off + no table model | --no-ocr --no-tables | 14.3 s | 1.59 s |
Where the time goes#
Docling profiling timings (settings.debug.profile_pipeline_timings), measured by docling.org.
Show data table
| Layout | OCR | Tables | Parse + assemble | Total | |
|---|---|---|---|---|---|
| Default (OCR auto + tables) | 15.5 | 61.0 | 11.6 | 0.7 | 88.7 |
| OCR off | 13.2 | 0.0 | 12.8 | 0.9 | 26.8 |
| OCR off + fast tables | 12.7 | 0.0 | 8.3 | 0.8 | 21.8 |
| OCR off + no table model | 13.5 | 0.0 | 0.0 | 0.8 | 14.4 |
With default settings, OCR dominates. The technical report is a born-digital PDF, so its text comes straight from the file — OCR only ran on the embedded figures (screenshots and charts), which still cost 61 seconds across 9 pages. In exchange it found about 5,000 more characters of text inside those images (34,063 vs 29,036 characters of Markdown).
How we measured#
- Machine: 4 vCPU x86_64 cloud instance, 15 GB RAM, no GPU, Linux, Python 3.13, PyTorch 2.14.1 CPU build.
- Software: Docling 2.143.1, docling-parse 7.23.1, docling-ibm-models 4.0.4; default models (Heron layout, TableFormer accurate, RapidOCR via the auto engine).
- Document: the Docling Technical Report, arXiv 2408.09869 — 9 pages, 3 tables, several figures.
- Method: one
DocumentConverterper configuration, one warm-up conversion, then three timed conversions in the same process; we report the median. Stage times come from Docling's built-in profiler (settings.debug.profile_pipeline_timings = True).
Run the same profile on your own documents:
docling convert your.pdf --profiling # prints a per-stage table
docling convert your.pdf --profiling --save-profiling # also writes it as JSONCold start vs warm#
A new process pays for model loading. For the OCR-off configuration our first conversion took 27.5 s; the next three took 20.8 s (median). In a service or batch job, create the converter once and reuse it — or use docling-serve, which loads models at boot.
Scanned documents#
Measured by docling.org: unique words (≥4 letters) of the born-digital text found in each output.
Show data table
| Words recovered | |
|---|---|
| Unstructured | 99.7% |
| Marker | 97.2% |
| Docling | 94.2% |
| PyMuPDF4LLM | 93.8% |
| MarkItDown | 0.0% |
We rasterised the first four pages of the same paper at 150 DPI with slight blur and skew, so there was no text layer at all. Docling's default pipeline recovered 94.2% of the original words at 20.4 s/page on CPU. MarkItDown, which has no local OCR, returned nothing; PyMuPDF4LLM returned nothing until Tesseract was installed. Swapping Docling's OCR engine to Tesseract gave 95.1% at 6.8 s/page, and RapidOCR on onnxruntime halved the default time (8.7 s/page) with identical output. For volumes of scanned documents, a CUDA GPU or Apple Silicon makes the biggest difference — see the OCR guide for engine choices.
Settings that change speed#
| Setting | CLI | Effect |
|---|---|---|
| Skip OCR | --no-ocr | 3.7× faster in our test on a born-digital PDF |
| Fast tables | --table-mode fast | 11% faster end-to-end in our test |
| Threads | --num-threads N (default 4) | Use your physical core count |
| Device | --device auto|cpu|cuda|mps|xpu | auto picks the best available |
| Page batch | --page-batch-size N (default 4) | Larger batches help on GPUs |
| Fewer pages | --page-range 1-5 | Only convert what you need |
| Safety net | --document-timeout 300 | Partial result instead of a stuck job |
| No models at all | --pipeline native (+ --parser-threads N) | Model-free: only the PDF's own text cells and images — no layout, headings, reading order or tables. Fastest, least structured. |
| Memory | --release-native-memory-every-n-pages N (default 128) | Lower it if long documents use too much RAM |
The Python equivalents live in PdfPipelineOptions and AcceleratorOptions — see the Python API guide.
What IBM reports#
The Docling technical report (v1, August 2024) measured an older version on a 225-page test set with OCR disabled: 1.27–1.34 pages/s on an Apple M3 Max and 0.60–0.92 pages/s on an Intel Xeon E5-2690, using 4 and 16 threads. Those are faster machines than ours and an older Docling, so treat the numbers as context rather than a comparison.
Frequently asked questions
How long does Docling take per page?
On our 4-vCPU test machine without a GPU, Docling 2.143.1 took 8.5 seconds per page with default settings, 2.3 seconds per page with OCR disabled, and about 20 seconds per page on a scanned document that needed full OCR. Your numbers depend on CPU, GPU and document type.
How do I make Docling faster?
Disable OCR for born-digital PDFs (--no-ocr), use --table-mode fast, convert only the pages you need (--page-range), raise --num-threads on machines with more cores, reuse one DocumentConverter, and use a GPU for OCR-heavy or VLM workloads.
Does Docling use the GPU automatically?
Yes. With --device auto (the default) Docling picks CUDA, then Apple MPS, then Intel XPU, then CPU, provided your PyTorch build supports that device.
Why is the first Docling run so slow?
The first run downloads and loads the models. In our test the first conversion in a fresh process took 27.5 seconds versus 20.8 seconds for the same document once the models were loaded.
Sources
- Docling profiling: settings.debug.profile_pipeline_timings
- Test document: Docling Technical Report (arXiv 2408.09869)
- Docling technical report, Table 1 (IBM's own runtime figures)