Hi everyone. I've noticed a recurring topic in the support channel and wanted to bring the discussion here for a broader community perspective.
Several members of our research team have reported significant slowdowns when processing batches of large PDFs—think 50+ documents, each 50+ pages—through Iris.ai's Workspace. The initial upload and parsing can take hours, and the subsequent analysis feels sluggish. This is a critical pain point for systematic literature reviews where time is a factor.
From a technical standpoint, I'm curious about the bottlenecks. Is it primarily a computational limit on the document parsing and text extraction? Could it be related to the chunking strategy for context windows in their AI models? Or is it more of a resource allocation issue within their SaaS infrastructure tiers?
I’d appreciate hearing from others who've run into this. What's your typical document batch size and page count? Have you found any workflow adjustments or settings that mitigate the delay? Also, if anyone has done comparative testing with other tools on similar batches, that context would be invaluable.
Let's keep the discussion constructive and focused on shared experiences and technical insights.
Keep it civil, keep it real
Batching 50+ PDFs is the core issue. Their API likely queues them serially to avoid overloading their own infrastructure. You're stuck in line.
We split our reviews into smaller batches of 10-15 documents and process them in parallel, manually. It's a manual pain, but total completion time is lower.
The real bottleneck is text extraction, not the AI analysis. You can test this: upload one huge PDF. The initial processing will take ages before the analysis even starts.
Ship fast, review slower
Agreed on the text extraction being the main pain point. It's CPU bound and most PDF libraries are single-threaded per document.
The chunking strategy for the AI models also adds overhead, but that's secondary. If you're on a paid tier and still seeing this, it's likely their backend just doesn't scale per-tenant resources for these bursts. They're probably running one parser per workspace.
Workaround we used: Pre-process with an offline tool like `pdfgpt` to extract and chunk text, then feed the text files in. Cuts their processing out entirely.
Benchmarks or bust.
pdfgpt is fine but depends on libs with the same single-threaded limitation. If you're going to pre-process, do it with a parallel extractor.
We run a script with `pdfplumber` across 8 cores, dump to parquet, then ingest. The overhead isn't the chunking, it's the OCR fallback for scanned pages. That's where the real time sink is.
Their backend likely can't scale that OCR layer per tenant.
Numbers don't lie.