Spire.PDF FindText OutOfMemoryException for x86 apps

[VolodymyrKhrushch]

Good morning E-Iceblue team!

I'm using the Spire.PDF library on one of my RPA (Robotic Process Automation) projects (based on the UiPath) and have to admit that your library really does its job, thank you! But I'm also forced to add, that at the same time I'm encountering a problem while trying to use your FindText method to find some common word (say, "the") in the huge pdf-file (1000+ pages). You may say that on modern machines even that shouldn't be a problem -- and yes, you may be right. But UiPath Studio itself (a variable, which can't be changed in my equation, in my case) adds one more restriction -- UiPath Studio's main executable application is still written for x86 logic and so doesn't support more than 2 GB of RAM. And for this particular case, 2 GB, unfortunately, looks like, isn't enough.

Can you please share any ideas of how a FindText method can be optimized to fit 2 GB limit? I'll appreciate any generic ideas too, without measuring and checking if exactly 2 GB limit was crossed or not (yes, I do know about the virtual memory, the pagefile). Or maybe you're currently working on some optimization of this method internally?

While understanding that I've provided not a lot of specific information:
1. My library version is: 5.9.16.2046. I do see that it's not the latest version, but I also can't find any updates brought for a FindText method in changelogs of the newer versions.
2. This issue doesn't show up and used resources are being freed by .NET Garbage Collector successfully in case the application, which contains SpirePDF.dll as the reference, was relaunched, in one way or another (completely or partially).
3. Intensification of Garbage Collector calls, moving FindText calls into separate thread, attempts to dispose returned resources (attempts, because native Spire.PDF models don't implement IDisposable, in most cases), slowing thread down a bit -- didn't show any positive effect. Calling FindText method separately as a delegate even made things worse.

Thank you in advance and take care of yourself!

[lynn.zhang]

Hi,

According to the scenario you described, I simulated and tested a PDF with 2000 pages on the x86 platform, but there was no OutOfMemory exception on our side. Generally, the more document data and the more complex the document structure, the more memory it consumes. In order to help us reproduce your problem, please offer your PDF file and your code. Then our developers will analyze your document structure in detail to evaluate whether the memory optimization is possible or not. It would be better if you could offer your project for investigation.
You could also send your files to support@e-iceblue. Thanks for your assistances in advance.

Sincerely,
Lynn
E-iceblue support team

[VolodymyrKhrushch]

Thank you, an issue has got not fixed, but "suspended", by updating a library to the latest version (6.8.5). Not fixed because the amount of RAM, consumed by the process, still grows up, periodically and stable. But this time, after updating, it grows up much slower.

I'd like to help you reproduce this error, but I'm not allowed to share this project. Since the error is both common and self-explanatory -- I believe you'll find a solution in future if needed, on your own.

Take care!

[Betsy.jiang]

Hi,

Thanks for your information.
Glad to hear the latest version has positive results on the memory issue. We simulated your case but didn't reproduce the exception before. Note each document has its own unique structure. Different elements may need different solution. So we need your file to find a good solution for your issue.

You could provide a sample project as long as the issue could be reproduced. And you colud send it to us([email protected]) via email.

Many thanks,
Betsy
E-iceblue support team