Performance optimization for batch processing on older Xeon architecture using PDF-Tools SDK

[dapemo9713]

Hi everyone,
I’ve been working on a custom document archival service for a few months now, and I’ve integrated the PDF-Tools SDK to handle some heavy-duty batch optimization and OCR. For the most part, the libraries have been fantastic and very straightforward to implement into my C++ environment. However, I’ve run into a bit of a performance wall that I’m trying to troubleshoot, and I’m hoping someone with more experience in high-volume processing might have some insight.
To give you some context on my environment, I’m currently running the processing engine on a dedicated legacy workstation. It’s an older but very reliable setup featuring an Intel Xeon Quad Core clocked at 3.50GHz [url]https://serverorbit.com/cpus-and-processors/xeon-quad-core/3-50ghz-5gt-dmi[/url]. It’s one of those older Ivy Bridge-era chips with the 5GT/s DMI bus. I’ve always been a bit of a "hardware recycler"—I’d much rather keep a rock-solid workstation like this running than cycle through new hardware every two years, especially since this Xeon has been a tank for my other backend tasks.
The specific point I’m struggling with involves the SDK’s optimization functions during multi-threaded execution. When I’m processing several hundred PDFs simultaneously (ranging from 50MB to 500MB each), I notice that the CPU utilization spikes to 100% across all four cores and stays there for significantly longer than I expected. Specifically, I’m looking at how the DLL handles image downsampling and re-compression internally.
I’m starting to wonder if I’m hitting a bottleneck related to my hardware’s architecture. While the 3.50GHz base clock is still fairly snappy for raw math, the 5GT/s DMI (Direct Media Interface) is quite dated compared to modern throughput speeds. I suspect that as the SDK tries to shuttle massive amounts of uncompressed image data back and forth between the memory and the CPU during the optimization process, the system might be choking on the bus speed rather than the actual processing logic of the library.
I’ve tried tweaking the PXP_Layout_Optimize parameters to reduce the complexity of the task, but the "hang time" on large files remains pretty consistent. I really don't want to have to retire this machine just yet if there is a way to optimize the way the SDK interacts with the memory or perhaps a way to throttle the thread priority so it doesn't saturate the DMI bus so aggressively.
Has anyone else noticed a significant performance delta when running the PDF DLLs on older Xeon or server-grade hardware versus modern consumer chips? I'm curious if the newer instruction sets in modern CPUs make that much of a difference for PDF compression, or if I should just look into optimizing my buffer sizes within the SDK calls.
Is it possible that the older bus speed is effectively "starving" the Quad Core of data to process, or am I likely just seeing the limits of 4-core multi-threading for modern PDF standards?