How to improve PDF conversion speed for large documents?

[Blue-Ladder]

pipeline_options = PdfPipelineOptions()
pipeline_options.images_scale = 1.0
pipeline_options.do_ocr = False
pipeline_options.generate_page_images = False
pipeline_options.generate_picture_images = True
pipeline_options.generate_table_images = True
pipeline_options.do_table_structure = True

doc_converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)
    }
)
conv_res = doc_converter.convert(input_doc_path).document 

I'm working on extracting images and tables from PDFs, chunking them using HybridChunker, and then linking each chunk with its corresponding images and tables. However, when dealing with large PDFs (over 500 pages), the document conversion process takes too long. What settings should I configure to improve the conversion speed? My environment has a T4 GPU and 2 CPU cores.

[dosubot]

Hi @Blue-Ladder! I'm Dosu and I’m helping the docling team.

To speed up PDF conversion for large documents, focus on these settings and strategies:

• Set images_scale=1.0 (no upscaling) to minimize memory and processing time without hurting table/image extraction quality (source).
• Disable generate_page_images and generate_picture_images unless you absolutely need them—both slow down processing, especially for large PDFs (source, more).
• The generate_table_images option is deprecated; to get table images, set generate_page_images=True and use TableItem.get_image, but be aware this will slow things down (source).
• Use ThreadedPdfPipelineOptions to enable batching and parallelism. Set ocr_batch_size, layout_batch_size, and table_batch_size (defaults are 4; higher values may help for layout/OCR on GPU, but table batching is still CPU-bound) (source, more).
• Set accelerator_options to use your GPU: device='cuda', num_threads=2 (to match your CPU cores). You can also set DOCLING_NUM_THREADS or OMP_NUM_THREADS as environment variables (source, more).
• Use the pypdfium2 backend for fastest PDF parsing (source).
• Profile your pipeline with profile_pipeline_timings=True to pinpoint bottlenecks (source).
• For very large PDFs, consider processing in smaller batches using page_range or splitting the file to avoid memory exhaustion (source).

Table extraction (do_table_structure=True) is inherently slow for table-heavy or complex documents and may remain a bottleneck even with all other optimizations. GPU acceleration helps with OCR and layout, but table extraction is still mostly CPU-bound (source).

If you only need tables, disable all other enrichment and image options for best speed (source). If you need both images and tables, keep only the minimal required options enabled.

Example config for your environment:

from docling.datamodel.pipeline_options import ThreadedPdfPipelineOptions, AcceleratorOptions, AcceleratorDevice
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat

pipeline_options = ThreadedPdfPipelineOptions(
    do_ocr=False,
    do_table_structure=True,
    generate_page_images=False,
    generate_picture_images=True,  # Only if you need images
    images_scale=1.0,
    accelerator_options=AcceleratorOptions(
        device=AcceleratorDevice.CUDA,
        num_threads=2  # Match your CPU cores
    ),
    ocr_batch_size=4,
    layout_batch_size=4,
    table_batch_size=4,
    profile_pipeline_timings=True,
    pdf_backend="pypdfium2"
)

doc_converter = DocumentConverter(
    format_options={InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)}
)

If you still see slowdowns, check if HybridChunker or downstream steps can be parallelized, and monitor GPU utilization with nvidia-smi to ensure the pipeline is using your T4 GPU effectively.

For more details and code examples, see the Docling GPU optimization guide and performance tuning discussions.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Blue-Ladder]

@dosu

If I don't enable generate_picture_images, I can't extract images though?
I'm still getting table images through generate_table_images and this seems faster.
If I use the pypdfium2 backend, doesn't it only improve speed while reducing structural analysis capability?
The Hybrid chunking results are different when I use do_table_structure=True versus when I don't. When do_table_structure=True, I get more chunks and the performance seems better. What about using TableFormerMode.ACCURATE for table structure options?

[dosubot]

Yes, you need to enable generate_picture_images to extract images (as PictureItems) from PDFs—if it's off, images won't be extracted or attached to the document. There isn't an alternative for image extraction without this flag.

You're still getting table images with generate_table_images, but that option is deprecated and will be removed; the recommended approach is to enable generate_page_images and use TableItem.get_image, though this is slower than the deprecated method (source). If you only need table structure and not the images, you can disable all image generation for better speed.

The pypdfium2 backend is faster and more memory efficient, but it does reduce structural analysis quality—especially for table structure extraction. For complex tables where quality is critical, the default docling-parse backend with the TableFormer model is recommended (source).

When you set do_table_structure=True, the pipeline runs the table structure model and creates detailed TableItem objects. This causes HybridChunker to produce more, finer-grained chunks (each table is chunked separately), which improves chunk-to-table alignment but increases processing time (source).

TableFormerMode.ACCURATE is the default and loads a more accurate but slower model for table structure extraction. Use it for difficult tables where quality matters. If you want faster extraction and can tolerate lower accuracy, switch to TableFormerMode.FAST (source).

If you want the fastest possible pipeline and only need tables (not images), disable all image generation and enrichment features, and use do_table_structure=True with TableFormerMode.FAST. If you need both images and tables, keep only the minimal required options enabled.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Blue-Ladder]

@dosu
Does using pypdfium2 reduce overall PDF structure parsing capability beyond just table analysis?
If so, could that lower the quality of HybridChunker results?
Can I still get image positions even if I disable image generation features?
If I can get the positions, is there a way to extract the images directly myself?
Is using do_table_structure=True with TableFormerMode.FAST faster and better performing than using do_table_structure=False?
What is the function of profile_pipeline_timings=True?

[dosubot]

Yes, using the pypdfium2 backend reduces overall PDF structure parsing capability—not just for tables, but also for headings, reading order, and figure boundaries. It produces more fragmented text cells and less detailed structural information compared to the default docling-parse backend. This can lower the quality of HybridChunker results, since HybridChunker relies on rich structural annotations to produce well-aligned chunks (source, source).

Image positions (bounding boxes) are still available in the document model as provenance information, even if you disable image generation features. These positions are recorded during the reading-order assembly stage, before image extraction options are applied (source). If you have the bounding boxes and access to the original PDF (or page images), you can extract images yourself by re-rendering the page and cropping to those bounding boxes using a PDF backend like pypdfium2 (source).

Using do_table_structure=True with TableFormerMode.FAST is faster than ACCURATE mode and provides better chunking and table alignment than do_table_structure=False, but with less accuracy in table structure extraction. If you want speed and can tolerate lower table accuracy, FAST mode is a good compromise (source, source).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Blue-Ladder]

@dosu
What is the function of profile_pipeline_timings=True?

Is using do_table_structure=True with TableFormerMode.FAST less accurate in structure extraction than using do_table_structure=False with TableFormerMode.ACCURATE?

[dosubot]

profile_pipeline_timings=True enables detailed timing profiling for each stage of the Docling pipeline. When set, it records how long each step (like document parsing, enrichment, table extraction, etc.) takes, storing per-stage durations, counts, and timestamps in the result.timings dictionary. You can access this data programmatically or as a timings.json file after conversion to pinpoint bottlenecks and optimize performance. Example scripts show how to enable profiling and analyze the results for tuning your pipeline source.

For table structure extraction: do_table_structure=True enables the TableFormer model, and TableFormerMode.FAST is a speed-optimized but less accurate version compared to TableFormerMode.ACCURATE. If you set do_table_structure=False, no table structure extraction is performed at all—so you get no table structure, just raw text or basic cell grouping. Therefore, TableFormerMode.FAST (with do_table_structure=True) is always more accurate than disabling table structure extraction entirely (do_table_structure=False), but less accurate than ACCURATE mode source.

If you want the best speed/accuracy tradeoff, use do_table_structure=True with TableFormerMode.FAST, and use pipeline profiling to see if table extraction is your main bottleneck. If you need the highest table accuracy, use ACCURATE mode, but expect slower processing source.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}