3x memory consumption between docling versions

[Highmoonlander]

Question

I am currently using the latest docling version 2.60.1
when parsing a very large pdf of 7000 pages the memory consumption for v2.60 sky rockets where as if i use v2.16.0 the memory consumption is controlled and reduced by 3 times

Any fix for the same ?
I tried using split , convert and merge technique but still memory consumption remains same

[dosubot]

The spike in memory usage in docling v2.60.1 is due to major changes in the PDF parsing backend and pipeline. The default backend (docling-parse v2/v4) now builds a detailed intermediate representation for every page, keeping all text cells, images, and geometry in memory, which quickly exhausts RAM for very large PDFs. The new threaded pipeline also increases the number of pages and parsed payloads held in memory at once, further increasing memory pressure, especially for documents with thousands of pages or complex layouts [source].

Here’s how you can reduce memory usage in v2.60.1:

• Switch to the PyPdfiumDocumentBackend: This backend extracts only what’s needed for each page and releases resources promptly, keeping memory usage low and predictable. You can select it with the --pdf-backend pypdfium2 CLI flag or in code:

  from docling.document_converter import DocumentConverter, PdfFormatOption
  from docling.datamodel.base_models import InputFormat
  from docling.backend.pypdfium2_backend import PyPdfiumDocumentBackend
  
  converter = DocumentConverter(
      format_options={InputFormat.PDF: PdfFormatOption(backend=PyPdfiumDocumentBackend)}
  )
  result = converter.convert("yourfile.pdf")

  [source]

• Tune pipeline options: Set generate_parsed_pages=False (default in recent versions) to avoid keeping parsed page data in memory. Disable enrichment features like formula/code/picture extraction unless you need them. Reduce batch sizes and queue sizes if you’re running into memory limits:

  from docling.datamodel.pipeline_options import PdfPipelineOptions
  
  pipeline_options = PdfPipelineOptions(
      generate_parsed_pages=False,
      do_formula_enrichment=False,
      do_code_enrichment=False,
      do_picture_classification=False,
      ocr_batch_size=2,
      layout_batch_size=2,
      table_batch_size=2,
      queue_max_size=20,
  )

  [source]

• Explicitly unload resources: After conversion, call unload() on the backend and page backends to free memory. Python’s garbage collector won’t do this automatically:

  result = converter.convert("yourfile.pdf")
  result.input._backend.unload()

  [source]

• Process in batches: Use the page_range or page_batch_size options to process large PDFs in smaller chunks. This helps control memory usage, but note that splitting affects heading detection and multi-page tables/lists—they’ll be treated as separate entities and not automatically merged [source].

• Trade-offs: The PyPdfium backend is fastest and most memory-efficient, but may miss advanced structure (tables, headings) compared to v2/v4. If you need the best table/structure extraction, use v2/v4 with careful batching and cleanup, but expect higher memory usage [source].

If you still see high memory usage after these changes, there may be unresolved leaks or limitations in the latest version, especially with enrichment features or very large/complex PDFs [source].

Let me know if you need example configs for your specific workflow or want more details on backend selection!

To reply, just mention @dosu.

---

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

   

[dolfim-ibm]

You could try two things:

1. Make sure that all the Docling libraries are the latest version.
2. Review the PdfPipelineOptions as posted above.

[Highmoonlander]

@dolfim-ibm
Hi
I did try these settings but still results are the same
I am not able to parse a very large pdf not even after splitting coz idk why and how it is taking all available memory every time

[petrosDemetrakopoulos]

Have the same issue even with the latest version, memory gets to exorbitant levels even when using PyPdfiumDocumentBackend with these options and calling the result.input._backend.unload() right after conversion.
PdfPipelineOptions( ocr=True, backend=PyPdfiumDocumentBackend, page_batch_size=2, do_picture_classification=False, do_code_extraction=False, do_formula_extraction=False, ocr_batch_size=2, layout_batch_size=2, table_batch_size=2, queue_max_size=20, )
The document is just 10 pages (high quality and including images though), approx. 1.5MB.

[vaclcer]

Exactly. So far I could not pinpoint it to the specific version, but latest releases (2.66 and 2.65) are using much more VRAM than the previous versions. With the same setting, I could run 5 workers fine, now it fails fast even with 4 during parallel conversions.

I do not want to be that guy.. but this needs to be CI tested before each release and it needs to be at least mentioned in release notes. Nobody enjoys tuning PdfPipelineOptions after each docling release :/

[dolfim-ibm]

Could this be related to what has been reported here? #2788