1. Olan Knight
  2. PowerBuilder
  3. Wednesday, 14 April 2021 15:08 PM UTC

I finally identified the cause of the performance slowdown in both PBv12 and PB2019R3. The problem is the DBPARM option "DisableBind=1".

Removing the DISABLEBIND=1 from the DBPARMS resolves the issue in both PBv12.1 and PB2019R3.
 
Solution:
Change the DBPARM
   from this:
        SQLCA.DBParm = "DelimitIdentifier='No', DisableBind=1, PackageProcs=1, STATICBIND=1"
   to this:
         SQLCA.DBParm = "DelimitIdentifier='No', PackageProcs=1, StaticBind=1"


Olan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



PBv12.1 b7055 & PB2019R3 b2670
Oracle 12C
Windows 64 bit platform


The main function of our primary app is to generate invoices. All of the code is internal to Powbuider, using PB script, DWs, and embedded SQL.  We have migrated this huge app to 2019R3 and like it, but we've run into a show-stopper:  the 2019R3 version of the app is 5 times slower than the PBv12.1 version when generating invoices.

In a desperate attempt to gain processing speed, I have compiled the app into Machine Code, i.e. DLLs instead of PBDs. We tested the DLL version of the 2019R3 app against the PBD version ofthe PBv12.1 app, and the 12.1 version was 5 times faster. Five large invoices (a very small subset) required 7.1 seconds in v12.1 and required 29.7 seconds in 2019R3. We tested with the exact same code on the exact same platform using the same invoices running against the same database.

I've no idea why 2019R3 is so much slower, and I really did not expect that to be the case. But it is what it is, and it's a show-stopper. We will not deploy the 2019R3 version of the code until the processing performance matches that of PBv12.1, or at least get close to it.

This is a shame, because 2019R3 is the preferred version, and the code it creates works with the Windows 2019 server under Citrix, and the 12.1 version does NOT. So....we'd LOVE to migrate, but cannot do so at this time.


Q1: Does anyone have any suggestions on how to speed up the processing of 2019R3?


I expected the DLL version of the application to be significantly faster than the PCODE version, yet the  performance of both versions of the code was nearly identical.
Q2:  Was my expectation unrealistic?

Q3:  Does having the "Enable DEBUG Symbol" option checked make any difference?

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 14 April 2021 15:18 PM UTC
  2. PowerBuilder
  3. # 1

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.

Comment
  1. Olan Knight
  2. Wednesday, 14 April 2021 22:56 PM UTC
I'll work on getting a test case for you. Thank you.

  1. Helpful
  1. Olan Knight
  2. Thursday, 29 April 2021 13:06 PM UTC
We have started tracing the processing to identify the source of the issue, if there is a single source.
  1. Helpful
  1. Olan Knight
  2. Tuesday, 10 August 2021 13:12 PM UTC
Update: Real life has interfered with this testing, so it has been put on hold until production issues & requirements have been met. I >>> WILL <<< get back to this.



Note: the 4GB_FIX.EXE did NOT speed up the performance of outr main app:

Main app:

PB 2019R3

PFC

MDI application
  1. Helpful
There are no comments made yet.
Tobias Roth Accepted Answer Pending Moderation
  1. Wednesday, 14 April 2021 20:03 PM UTC
  2. PowerBuilder
  3. # 2

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

Comment
  1. Olan Knight
  2. Wednesday, 14 April 2021 22:56 PM UTC
That's a great idea, and I'll try it! Thank you!
  1. Helpful
  1. Benjamin Gaesslein
  2. Thursday, 15 April 2021 06:22 AM UTC
The tracing tools can be very helpful in pinpointing performance issues, indeed. Make sure to enable tracing in the system options first ("Profiling" tab) but you probably know this.
  1. Helpful
  1. Olan Knight
  2. Thursday, 29 April 2021 13:05 PM UTC
We have started tracing the processing to identify the source of the issue, if there is a single source.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 14 April 2021 23:11 PM UTC
  2. PowerBuilder
  3. # 3

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.

Comment
  1. Miguel Leeuwe
  2. Wednesday, 21 April 2021 16:53 PM UTC
FYI: the latest MR claims that the ACCESSIBILITY should be working again.

regards
  1. Helpful
  1. Olan Knight
  2. Wednesday, 21 April 2021 22:03 PM UTC
Thanks, Chris, I'll try the DLLs set to "Optimize for speed" using the new R3 MR.
  1. Helpful
  1. Olan Knight
  2. Tuesday, 10 August 2021 13:09 PM UTC
Well....I added the accessibility PBDs, AND set ACCESSIBILITY=NO in the pb.ini file. I also "optimized for speed".

No difference in performance.



All of the processing done is internal to the app, and there ARE instances of nested loops where data from the DW referenced in the outer loop is used as parent data for the children processed in the inner loops. There's not more than a "normal" amount of transaction data; i.e. no massive data loads are occurring.



This is looking more and more like the 2019R3 PBVM engine is simply slower than the PBv12.1b7055 PBVM engine. However, I shall keep on searching for more information and a way to speed up R3.

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 15 April 2021 15:49 PM UTC
  2. PowerBuilder
  3. # 4

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

Comment
  1. Armeen Mazda @Appeon
  2. Thursday, 15 April 2021 16:09 PM UTC
Please let us know if Miguel's suggestion resolves the performance issue. Thanks.
  1. Helpful
  1. Miguel Leeuwe
  2. Thursday, 15 April 2021 16:53 PM UTC
Thanks for letting me know Chris! I'll remove it too!
  1. Helpful
  1. Olan Knight
  2. Friday, 16 April 2021 23:16 PM UTC
No noticable difference in performance with or without a PB.INI file.

:(
  1. Helpful
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Thursday, 15 April 2021 15:45 PM UTC
  2. PowerBuilder
  3. # 5

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

Comment
  1. Miguel Leeuwe
  2. Thursday, 15 April 2021 16:57 PM UTC
Olan,

the entry "[RichTest]", should that not be "[RichText]" (with an 'x') ?
  1. Helpful
  1. Miguel Leeuwe
  2. Thursday, 15 April 2021 17:00 PM UTC
Yes, that's definitely a spelling error.
  1. Helpful
  1. Olan Knight
  2. Friday, 16 April 2021 23:17 PM UTC
No noticable difference in performance with or without a PB.INI file.

:(
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 15 April 2021 17:00 PM UTC
  2. PowerBuilder
  3. # 6

Hi Olan,

About your pb.ini file:

the entry "[RichTest]", should be "[RichText]" (with an 'x')
Comment
  1. Miguel Leeuwe
  2. Friday, 16 April 2021 23:33 PM UTC
Sorry to hear that, it was worth a try. So what's taking the most time in you process?
  1. Helpful
  1. Olan Knight
  2. Wednesday, 21 April 2021 22:01 PM UTC
Have not yet had an opportunity to sit down and run the testing, but I have NOT forgotten!

I'll get back to this thread as soon as I get those test results!



Thank You!
  1. Helpful
  1. Olan Knight
  2. Thursday, 29 April 2021 13:04 PM UTC
We have started tracing the processing to identify the source of the issue, if there is a single source.

  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Thursday, 15 April 2021 17:26 PM UTC
  2. PowerBuilder
  3. # 7

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?  

 

Comment
  1. Olan Knight
  2. Thursday, 15 April 2021 19:06 PM UTC
Thank you for the information, Mike.



1) Nope, I have no embedded reports during the processing under discussion.

2) Yes, I use three global functions, but NOT in the datawindows - only in script.
  1. Helpful
  1. mike S
  2. Thursday, 15 April 2021 19:34 PM UTC
can you verify if is slow down is in the retrieve of the datawindows? time the same retrieve in 12.1 vs 19 to see if that is where it is slower.



if that is where the slow down is, then check things like packet size used, the binds, and also compare the oracle driver used. The packet size can make a big difference
  1. Helpful
  1. Olan Knight
  2. Friday, 30 April 2021 03:43 AM UTC
I have activated tracing so we will be able to get actual retrieval times the next time we test.
  1. Helpful
There are no comments made yet.
Sivaprakash BKR Accepted Answer Pending Moderation
  1. Thursday, 29 April 2021 05:33 AM UTC
  2. PowerBuilder
  3. # 8

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

 

Comment
  1. Olan Knight
  2. Thursday, 29 April 2021 13:26 PM UTC
We are still struggling with this. We just started using the trace capability to see if there are identifiable issues, rather than this simply being the difference in the PBVM engines.



I'll update this thread as new information is acquired.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Thursday, 29 April 2021 15:05 PM UTC
Thanks Olan for keeping us updated!
  1. Helpful
There are no comments made yet.
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Thursday, 29 April 2021 15:25 PM UTC
  2. PowerBuilder
  3. # 9

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

 

Comment
  1. Ken Guo @Appeon
  2. Thursday, 5 August 2021 05:13 AM UTC
Can you tell us your testing result?
  1. Helpful
  1. Olan Knight
  2. Thursday, 5 August 2021 13:37 PM UTC
Test results were as follows: no difference at all.

- The PB2019R3 build 2703 code runs about 5x slower than PBv12.1 b7055.

- I included a pb.ini file with all of the suggestions made by Chris and Ken.

- I tried running with PBDs and with DLLs.



My conclusion is that the core functionality of PB2019R3 is just slower. Significantly slower. The only thing we can do right now to mitigate this is to strip the processing code from PBv12 and create a stand-alone EXE that can be called by the PB2019R3 app. I'm certainly open to any ideas or suggestions anyone might have.
  1. Helpful
  1. Miguel Leeuwe
  2. Tuesday, 10 August 2021 14:39 PM UTC
Another solution might be to use a Snapdeveloped assembly which uses a datastore and does whichever processing you have to do.

regards.
  1. Helpful
There are no comments made yet.
Monica Petersen Accepted Answer Pending Moderation
  1. Wednesday, 4 August 2021 23:27 PM UTC
  2. PowerBuilder
  3. # 10

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

 

 

Comment
  1. Olan Knight
  2. Thursday, 5 August 2021 15:43 PM UTC
Monica -

I ran the 4GB_FIX.EXE utility pointed out by Aart against my EXE and it resolved the memory issues I was experiencing AND it about t ripled to perfmance of my code!

https://ntcore.com/?page_id=371
  1. Helpful
  1. Ken Guo @Appeon
  2. Friday, 6 August 2021 06:45 AM UTC
Hi Olan,



Thanks for sharing the solution with us. This is very helpful for us to handle similar issues in the future.



Regards,

Ken
  1. Helpful
  1. Monica Petersen
  2. Friday, 6 August 2021 15:17 PM UTC
Thanks Olan, our app is now running much faster under R3!
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.