PBv12.1 and PBv2019R2
Oracle 12C
Windows 10, 64 bit, SP-1
We have this giant app that we migrated from PBv12.1 to PBv2019R2. Some users run from another continent through Citrix to the host VMs to run the app. Often, the users will each have multiple sessions running in order to theoretically get the required processing of multipe files done more quickly.
Yesterday, we ran the new 2019R2 version in a production run for the first time. All users noted that processing was really, REALLY slow. Files that should have taken 2 minutes to process were taking 30 minutes.
I tested by having everyone close all their sessions so that I was the only one running the app, and I'm in CONUS.... and the 2019 version of the app was slower than the v12 version, but MUCH faster than when all the users were in multiple sessions. Obviously.
Next I tested the two compilers by running the v12 app and the v2019R2 app against the same data in the same databases from the same VM. The v12 app was at least 6x faster. We know this because the start and stop times are logged.
1. Has anyone else noticed this performance difference?
2. Some research turned this info up:
PBVM is consantly looking for a DLL calld "pbdynamictab190". There is no reason for this DLL and it is not distributed with 2019R2. At runtime, the PBVM is constantly issuing a load instruction. The PVBM doesn't care if the load fails though and then continues, but this load searching is continuous....
and from Chris:
While this behaviour is not too bad when the App is deployed to a local machine, this constant DLL searching could be a "killer" when PB Apps are run via Citrix, RDP or from a network Share drive. This could constantly invoke significant network overhead. Food for thought.
3. I think that I have seen that the issue noted above in item #2 was resolved with 2019R3.
Does anyone know if that is the case?
4. Are there any other issues that people have found relating to the performance of compiled EXEs in 2019?
Thank You,
Olan
I have added a new PB.INI file into the folder with the EXE that contains nothing but:
[Datawindw]
ACCESSIBILITY=0
We'll see how it goes! Thanks again for the suggestion.