Memory usage PXCp_ET_Prepare

[marcovdlinden]

We have a memory problem where our application runs out of membory

The situation:
3 pdf files, total size 629 MB and 140.000 pages
We have to open these files 2 times, for viewing and extracting text.
Memory usage after opening these files without calling PXCp_ET_Prepare is about 350mb extra.
Memory usage after opening these files with calling PXCp_ET_Prepare is about 1750mb extra.
If we call PXCp_ET_Finish after extracting text, the memory is not freed, also for performance reasons it is not an option to call PXCp_ET_Prepare and PXCp_ET_Finish frequently.

Is there any way to reduce the memory usage? Or why is it not freed with _Finish?

[Tracker Supp-Stefan]

Hi Marco,

Are you opening all the files at once? Also could you provide us with a sample set of files which we could test at our end?

Thanks,
Stefan

[marcovdlinden]

Yes we are, and we need to.

These PDF files contain letters to customers and we are sorting across 3 files to genererate one sorted file. And we do the sort based on the information found on these letters.
After that the user can take certain actions like scrolling trough the sorted pages, or print the document at which time we need to access pages across the 3 documents. And like you state in your manual opening the required pages one by one is not an option due to performance.

For example document see your support@ email

[Tracker Supp-Stefan]

Hi Marco,

Thanks for the sample file, but my colleagues from the dev team told me that it's stripped from alost everything, and is useless for testing at our end. Could you provide us with one complete file?

Regards,
Stefan

[marcovdlinden]

Done, see support@

[Tracker Supp-Stefan]

Thanks Marco,

Passed it on to my colleague for investigation.

Cheers,
Stefan

[Tracker Supp-Stefan]

Hello again Marco,

We did investigate your file and here are our comments:
This file has a lot of pages and therefore a lot of PDF objects (more than 241 000). When extracting text PDFTools loads almost all objects into memory and keeps them until the file is closed - this is the reason why Tools uses so much memory (it was simply not designed to be used with such massive files). So for now there is only one possible workaround - to open these files one at a time and close them after text extraction.
The long term solution would be our new SDK which should be able to handle such files without such dramatic memory usage.

Regards,
Stefan

[marcovdlinden]

Since we are merging these files, in the end, we'll have a single file, so no way to 'close' parts of that.

The intermittend problem is that just before we get 'out of memory' errors, the Teamtracker 'trial' license logo's start to appear in either the view or the output or both. Due to memory limitations (see one of my earlier forum posts https://forum.pdf-xchange.com/ ... 44&t=17094)
Which is dificult to explain to customers, and almost imposible to prevent.

Since this is an actual problem, we would be realy interested in the new SDK, when will (beta) releases be made available?

[Paul - Tracker Supp]

Hi marco,

I aked the development team leader about this. While the new SDK is still some time off, the part dealing with this is complete, though until it is ready with all functions it won't be released as a partial release so there is still a wait yet.

Regards the water marks, there is no obvious reason we can tell you about, we would need to reproduce the issue here. Are you able to put together a sample app that has the issue?

[marcovdlinden]

Any news yet on the new SDK yet?

As for the demo logo issue, first reported here: https://forum.pdf-xchange.com/ ... 44&t=17094
There is no easy way to demonstrate this other than by using our software (http://www.flex-systems.com/FlexMail/FlexMail.aspx)
And add the PDF from the other forum thread as a picture. and then print.

And do all this on an Windows XP machine, since the demo logo problem seems to be an exclusive XP problem.