For Spool File Page Counter SDK product,
https://www.verydoc.com/spool-page-count.html
VeryDOC support,
I have been evaluating your PDF Parser & Modify SDK for .NET download (ps-and-pcl-info-sdk.zip) as a solution to identify PDF files containing color from PDF files that are 100% Black & White. By redirecting the console to a file I can subsequently process with a reader routine it appears your product has a means of providing the information we need. I also notice on your product website that the DLL files can be integrated into our own applications. After downloading and testing I have 3 issues on which I would like feedback if you don't mind.
1. Execution time: When I run a test using the on a workstation running Windows 7 Enterprise SP1 64 bit on Intel Core i5-3550 @ 3.3 GHz processor (4 CPUs) with 4 GB RAM each PDF was taking 3-5 seconds to output info to the console with the most common time being 4 seconds. Running the same test on a server running Server 2008 R2 Standard SP1 64 bit on Intel Xeon X5650 @ 2.67 GHz 2 processors (24 CPUs) with 24 GB RAM each PDF was taking 2-3 seconds to output info to the console with the most common time being 2 seconds. The issue is that on a given application run we may have 5,000 or more PDF files to identify as color or black and white only and our processing window only allows a maximum of 1.5-2 hours to get that part done. Even at an average of 2 seconds per PDF file the time required is 10,000 seconds or about 2.8 hours. I know that looking for color directives in PDF is not a trivial task. Do you have any suggestions how to get faster throughput on the program to where the rate is an average of 1 PDF file per second? I am also wondering if integrating your dll objects into our applications will have a tendency to speed up or slow down the throughput experienced with the examples in the software download.
2. Integration with our apps: In an attempt to connect to namespace properties and methods in your product from a Visual Studio 2008 project I get a message that the dll files were not built in a way that exposes those objects for linking with software I develop. I can write the project to run a DOS shell that executes your program and then retrieve the log but your website indicates that the functionality of your program can be integrated into our own applications.
3. Server vs Developer: I first downloaded what the server version download button downloads and that is what I used in testing execution time because of pricing and using a robust server situation to process is most likely what we would be setting up. When I could not get the DLLs to link with a sample VS2008 program I created I considered that maybe the developer version has exposed DLLs. So I click the download button for the developer version and what was downloaded is identical to what the server download button downloaded. I did not go any further. Are there special mechanics involved when linking your DLL files to our applications. I want to be sure the performance and .NET linking of DLL files are achievable before I can consider recommending a purchase.
Thanks for your time and response to my questions. I look forward to hearing from you soon. My phone # is below if you think it would be better to share a verbal dialog.
Customer
----------------------------------------------------
>>1. Execution time:
The speed of our Spool File Page Counter SDK (ps-and-pcl-info-sdk) is already fast enough, it is need only 2 seconds per file. However, I have following solution to you if you wish improve the speed continue,
Multiple Processes:
You can run several instances of ps-and-pcl-info-sdk to check the color information of your PDF pages, multiple processes will utilize multiple core CPU completely, this will improve the speed for multiple files a lot.
You can also send to us some PDF files for checking, we will try to figure out a best solutions for your PDF files in order to improve the speed.
>>2. Integration with our apps
ReadInfo.dll is a 32bit DLL Library, it is not a COM component, you can call ReadInfo.dll from your source code directly, but you can't add a reference to it, please understand.
Also, ReadInfo.dll is a 32bit DLL Library, when you call it from your code, you need compile your source code with x86 compile option, if you compile your source code with x64 or AnyCPU on 64bit system, you can't call it properly, you will get "incorrect image format" error.
>>3. Server vs Developer:
Yes, you can call ReadInfo.dll from .NET code without any problem, you need call ReadInfo.dll from your .NET code directly and compile your code with x86 platform mode.
----------------------------------------------------
Thank you for the prompt response. The information you provided resolves my issues. I was able to call your product functionality from a simple .NET program and while I have not attempted a throughput test of multiple programs running concurrently to use more of the available cores it makes sense that doing so should result in an overall throughput increase.
Customer