Did this ever get resolved?  I had found the same issue, and was able to recreate it in a very simple app, that I attached to my issue.  In our case, the app went unresponsive each time you closed a window with a datawindow on it.

https://community.appeon.com/index.php/qna/q-a/closing-large-datawindows-in-pb2019r3-triggers-cpu-churn

Hi Olan，

For the performance problem, I suggest you try this:
1. Upgrade PB 2019 R3 Build 2670 to Build 2703.
2. Full build and deploy your application.
3. Add a pb.ini file in the directory where the EXE resides, this pb.ini file
contains the below content:
[Data Window]
ACCESSIBILITY=0
4. Try again to see if the problem still exists.

Regards,

Ken

Olan,

Can we know whether you could solve the 'speed' issue in 2019R3?   We are planning one new project in 2019R3.  

Happiness Always
BKR Sivaprakash

Q2 - dll - you generally won't see a difference if most of what your application is doing is datawindow oriented.  If you have large loops that take a lot of time to process in p-code then you probably will see the dll faster.

Can you tell if it the datawindows that are slower, or something in your script? 

If it is your datawindows that are slow, then -

1) are you using embedded reports on them?  that is fairly slow. 

2) are you using any type of global user functions in your datawindows?  

Hi Olan,

About your pb.ini file:

Hi Miguel;

  FYI: Note that the setting ...

NativePDF_IncludeCustomFont=1

is no longer supported in PB2019 R3. This option is now set in the Application Painter.

Regards ... Chris

Thank you for the suggestion, Miguel, I will try it!
After incorporating your suggestions, my pb.ini file currently contains the following entries.

[DataStore Behavior]
UseHwnd=no

[Data Window]
ACCESSIBILITY=0
ForgetColumnKeyboardLayout=Yes
NativePDF_IncludeCustomFont=1
NativePDF_Valid=1

[Debug]
VariablesWindow=0
WatchWindow=0

[Machine Code]

[pb]
AutoSetCurrentTarget=1
Dock=1 2001 0 1 13 68 0 0 426 229 2003 0 1 13 32 0 0 426 229
LastWorkspace=C:\APPS19\utilities\Utility - Cox Extracts.pbw
Maximized=0
PbCrashFlag=0
ReopenWorkspace=1
StartDialog=0
TestIni=PowerStudio
ToolbarText=0
ToolbarTips=1
UseSimpleMAPI=No
Window=641 22 1912 1208

[PostgreSQL]
DelimitIdentifier='NO'
ForeignKeyDeleteRule='Disallow if Dependent Rows Exist (RESTRICT),Delete any Dependent Rows (CASCADE),Set Dependent Columns to NULL (SET NULL)'
IdentifierQuoteChar='"'
PBCatalogOwner='public'
PBDateTime='STANDARD_DATETIME'
PBFunctions='PG_FUNCTIONS'
PBDefaultValues='current_date,current_time,current_timestamp,current_user'
PBDefaultCreate='YES'
PBDefaultAlter='YES'
PBDefaultExpressions='YES'
PBNoCatalog='NO'
PBQualifierIsOwner='NO'
PBSpecialDataTypes='PGSQL_SPECIALDATATYPES'
PBSyntax='PGSQL_SYNTAX'
PBTableOwner='YES'

[RichText]
PageSizeAsControlSize=1

[SQL Painter]
Hidecomments=0
Tabitem=1

Hi,

If you don't have these settings, please try and compare the performance when using a pb.ini file distributed next to your executable. See below our settings in the pb.ini.

I'm thinking especially of "UseHwnd=No" and "ACCESSIBILITY=0":

[PB]
UseSimpleMAPI=No

[DataStore Behavior]
UseHwnd=No

[Data Window]
NativePDF_IncludeCustomFont=1
ACCESSIBILITY=0
ForgetColumnKeyboardLayout=Yes

regards.

Hi Olan,

you could try to use the IDE internal tracing function (new, Tab "Tool" ) to locate the script that cause the problem.

As far as I remember the tracing lists timing information for every line of code. There are two tracing/profiling tools one of it contains the timing info. 

Both tools are also in PB 12.1. So it is maybe possible to compare the results

If it is possible to locate the line of code that cause the slowlyness, you should report it in the Appeon Ticket to speed up the analysis. 

Regards, 

Tobi

Hi Olan, please open a support ticket and please try to provide test case.  There is something really strange going on and we need to resolve this even if it only affects your particular app.