Hi Teegala ;

  The 3rd party tool that PB uses "under the hood" to drive the NativePDF feature basically cancels the performance efficiency of the SaveAs (PDF) feature in a multi-threaded App as it now behave more like "single threaded".

   I would suggest creating a batch PB App that takes two PSR file names as arguments. Then produces a PDF from those using a DataStore approach. The use the new PDF Builder in PB 2022 R2 to "stitch" the two PDF's together as required would be a key feature to use here (IMHO):  https://docs.appeon.com/pb/whats_new/PDF_Builder_enhancements.html

   Once the above batch PSR => PDF batch App EXE is ready, I would create another "Controller" PB App that uses the Run() command to call the batch PSR processing app passing a list of the PSR's to combine into one PDF. This technique should allow each batch App EXE to "bind" to a processor based on the O/S's decision. Thus, you can now have say for example 6 batch App exe's working simultaneously on 12 PSR's very efficiently as each batch App would have their own NativePDF internal thread working with them as well.

  The final "icing on he cake" for this architecture would be to replace the PB Run() command with a Run&Wait approach as in this free code: https://www.topwizprogramming.com/freecode_runandwait.html

   This would now allow the "Controller" App to monitor the sub-Apps and start a new one once a pair of PSR's were converted. Thus in fact, your controller App would now have a "governor" type capability as to the number of batch PSR Apps running at any time underneath it.

Food for thought.  HTH

Regards ... Chris