DrawToDevice performance

[pschlan]

Hi,

I'm experimenting with the Core API SDK to print PDFs. I have to keep a very fast printer busy, so performance is critical. I've noticed that the application often is stuck in DrawToDevice() while CPU usage / IO on the machine is low and my application itself uses like 0 % CPU, and I don't know where the bottleneck is.

In another experiment, I'm printing different files in parallel from multiple threads, and it seems like performance is not improving. Is there some global lock on the Core API side? I'm currently testing with very simple files, and some calls to DrawToDevice() are fast, while others (drawing the same page from the same file) seem to be slow.

Any idea how to speed up things?

Best,

Patrick

[Tracker Supp-Stefan]

Hello Patrick,

I've passed your enquiry to my colleagues from the dev team, and asked them to comment here!

Kind regards,
Stefan

[pschlan]

Thanks Stefan!

One update: I ran an experiment where I'm using multiple processes (instead of multiple threads), and this performs much faster. So it does seem to be an issue when calling this multiple times / in parallel in the same process. FYI, I do use a document instance per thread.

[pschlan]

Hello Patrick,

I've passed your enquiry to my colleagues from the dev team, and asked them to comment here!

Kind regards,
Stefan

Any news here?

[Tracker Supp-Stefan]

Hello pschlan,

Apologies for the delay here!
Your case has been passed on to a colleague in the dev team, but it seems like I will need to 'nudge' them a bit!
I've started the internal process, and should have further news for you very soon!

Kind regards,
Stefan

[Lzcat - Tracker Supp]

One update: I ran an experiment where I'm using multiple processes (instead of multiple threads), and this performs much faster. So it does seem to be an issue when calling this multiple times / in parallel in the same process. FYI, I do use a document instance per thread.

HI pschlan.
You are correct, issue is due to per process limitations in Windows API we are using. We have plans to migrate to a newer API in this function, but unfortunately there is no time frame for this and there is no warranty that this API will be much faster in multithreading scenario.
Glad you found at least one workaround and can purpose one more - you may set nFlags parameter to 0 (zero). This will render page to device as image (not as vector as in "problematic" method you are using). In this case multithreading should be working as expected, without need to run several processes. But this may change print quality and speed, so I cannot predict what will be better for your case.
Best, Victor.