• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Performance of Background Processing PB2019 LTR vs PB2017 LTR

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved Performance of Background Processing PB2019 LTR vs PB2017 LTR

  1. How-to
0
Votes
Undo
  1. Glenn Barber
    Glenn Barber
  2. PowerBuilder
  3. Thursday, 13 April 2023 20:02 PM UTC

We have a computational intensive background non-visual app which is run on a windows server.  It was written and compiled with PowerBuilder 2017 LTR. 

Largely it reads data from a SQL Server database in the network via a datastore, processes the data and writes new data out to the same database engine from another datastore.  Usually we run as many of these processes as possible on the server.  Typically in a few hours of processing it generates more than 100 million records in the target database.

The app has been running for years on Server 2012R2  and now upgraded the OS to 2019.

It seems to run faster on 2019 than on 2012r2 on the same hardware.

We started testing the same apps compiled under PB2019 LTR and immediately noticed a reduction in compute utilization and overall thruput.  

I am investigating the cause.

As we are fairly new to PB 2019 we wonder if the was a trick we were missing.

On 2017 LTR we had to include the following in the pb.ini to maximize thruput.
[datastore behavior]
usehwnd=no

is a similar feature needed in 2019 LTR and how is it used.

Has anyone else compared background computing like this between the two versions?

 

  1. Performance
  2. PowerBuilder
Datawindow - setfocus on non column with code
How to read QR Code using ZXing from Scanned Image...
Responses (3)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 13 April 2023 21:19 PM UTC
  2. PowerBuilder
  3. # 1

Hi Glenn;

  Here are the settings i use in my PB.ini for both the IDE and PB App runtime EXE...

[PB]
; create a debug log when running from development mode
PBDebug=ON
DebugOutFile = c:\\.dbg

; No = Extended MAPI
UseSimpleMAPI=yes

; Use 1 to force 8 Byte alignment. A value of 0 forces 1 byte alignment (before PB 12.6 changed the default)
UseZp1=0

; 0 = OFF, 1 = ON - used to force the PB2017Rx IDE to run your Apps in XP mode (old W7 look & feel)
; Note: Turning this feature option ON (1) will defeat the "Theme" feature in PB2019 & higher!
UseVer5Control=0

; Note: can also control this via external function declaration by adding “progma_pack(1)” at the end!
; FUNCTION int STLAREGIO ( ref struc_kfzrechnerneu struc_kfz ) LIBRARY "KFZ_SS.DLL" alias for "STLAREGIO;Ansi" progma_pack(1)
progma_pack(1) is 1-byte align, progma_pack(8) is 8-bytes align.  In this way, the effect is only for external function that is declared with this alignment. 

; Target the output of your Machine Code compiles to a specific location (IDE Only). For example ...
CODEGENTEMP=G:\PB2019\CplusPlus

; Use PB 11/12.x behaviour for Tab Pages (Allows background colours to be set)
UseVer5Control=1


[Data Window]
; Whether the NativePDF uses the desktop DC (device context) or the printer DC.
; 0 = (default) desktop DC or 1 = printer DC
NativePDFPrintDC=1

; 1 = Use Native, 0 = GhostScript or XLSFO
NativePDF_Valid=1

; 1 = Embed fonts in PDF, 0 = Do not embed fonts in PDF
NativePDF_IncludeCustomFont=1

; Use these settings when toggling between Left-2-Right and Right-2-Left data entry fields.
useDefaultKeyboardLayout=yes
RTL_NoAlignment=yes
ForgetColumnKeyboardLayout=yes

; Missing from every PB IDE installation
GenerateWSAssembliesOnCompile=YES
debug_ws_metadata=1

; Can improve the speed for large row retrievals ...
; 0: Disable both MSAA and Microsoft UI Automation - 1: Enable both - 2: Enable Microsoft UI Automation only - 3: Enable MSAA only
Accessibility=0

; Automatically reset keyboard layout (yes)
ForgetColumnKeyboardLayout=yes
; Force RTE DW's to use Default keyboard layout (yes)
useDefaultKeyboardLayout=yes

; For handling "default" printer(s) in Citrix environment (PB 2019 R3+)
Citrix=1

; Missing from every PB IDE installation to properly handle Web Service and WS based DWOs
GenerateWSAssembliesOnCompile=YES
debug_ws_metadata=YES


[DataStore Behavior]
; No = do NOT use MS-Window handles in DS processing (Default is yes). "No" gives much better performance!
UseHwnd=no

[dwconverter]
; PowerServer SQL Issue : Please see PS dcumenation!
; ColumnPlaceHolder = 0 means not to use a placeholder; ColumnPlaceHolder = 1 means to use a placeholder
; If you compile using PowerBuilder IDE, the configuration needs to be made in the user folder  %LocalAppData%\Appeon\PowerBuilder 22.0\pb.ini 
ColumnPlaceHolder = 1    



[DbTrace]
ShowDBINames=0
FetchBuffers=1
ShowBindings=1
SumTiming=1
Timing=1
ShowDialog=1 
LogFileName=dbtrace.log

; Disable the JVM if SCM connection problems exist
[JavaVM]
CreateJavaVM=0



[Library]
; 1=Low, 2=Medium, 3=High level of details
SccLogLevel=3

[ResourceMonitor] 
PerformResourceMonitoring=1
ResourceTestTimeout=5000


[RichText]
; An issue can occur because PowerBuilder sets the default page size to 8 1/2 x 11 for the control. 
; This setting bypasses the default.
PageSizeAsControlSize=1

[Edit Mask Behaviors]
AutocompleteDates=no

HTH

Regards .. Chris

Comment
Glenn Barber
  1. Glenn Barber
  2. Friday, 14 April 2023 16:44 PM UTC
besides the windows handles setting - can you think of anything else here that would me a huge difference in performance on background processing using datastores.? Or anything else in 2019 that we might need to change.
  1. Helpful
Arnd Schmidt
  1. Arnd Schmidt
  2. Sunday, 16 April 2023 18:03 PM UTC
Nice list!

But QA remarks: "Duplicate entries for:

GenerateWSAssembliesOnCompile=YES

debug_ws_metadata=YES / 1

in [Data Window] section".
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 13 April 2023 20:23 PM UTC
  2. PowerBuilder
  3. # 2

Hi Glenn .. Yes, the "usehwnd=no" setting would also apply to your "background" App compiled in either PB 2019, 2021 or 2022 as well. HTH

Comment
Glenn Barber
  1. Glenn Barber
  2. Thursday, 13 April 2023 21:05 PM UTC
I found your old thread on this from 2018 where you suggested this could be included in the IDE's pb.ini - would that supplant its need to be in a pb.ini in the exe directory? (doesnt seem to work there..or there is something else we are missing thats been changed in 2019)
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 13 April 2023 21:14 PM UTC
Hi Glenn;

For that App, you would need to add this to the PB IDE's PB.INI and then create a "Custom" PB.INI with that setting that then resides in the PB App EXE's deployment folder as well.

Regards ... Chris
  1. Helpful
There are no comments made yet.
mike S
mike S Accepted Answer Pending Moderation
  1. Thursday, 13 April 2023 20:21 PM UTC
  2. PowerBuilder
  3. # 3

in 2019, did you also include:

[datastore behavior]
usehwnd=no

 

 

 

Comment
Load more comments
mike S
  1. mike S
  2. Sunday, 16 April 2023 11:38 AM UTC
[Data Window]

ACCESSIBILITY=0



made a huge difference in my app on closing retrieved datawindows. So triple check that this is the case. However, i believe that was true in 2017 as well.





You should try 2022, a simple recompile should be all that is needed. Some of the string processing is faster, and i believe it uses newer version of c, so that could speed up other things.



Also, are you doing any of this in 64 bit?







"generates more than 100 million records" thats a lot. have you compared speed using different drivers (oledb, new oledb, odbc, 'native', etc.) along with things like packet size? I agree that if you are doing the same exact thing in 2017 vs 19 then this should not make a difference. However, I assume you are just looking to get the speed up, so this may be something to consider.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Sunday, 16 April 2023 19:21 PM UTC
Hi Mike,

"a simple recompile should be all that is needed" ... Unless you use lots of win API's and run 64 bit.
  1. Helpful
Glenn Barber
  1. Glenn Barber
  2. Monday, 17 April 2023 17:28 PM UTC
We went back to 2017LTS version and reran just to check if it was a fluke - its not - 2019LTR is about a 3rd as fast - same native drivers - 64 bit.

2022 might be interesting for testing purposes - but cant put into production until its under Long Term support. We are going to revert to 64 bit 2017 for production until we can sort out the issue - however it really looks like the windows handles fix in the pb.ini is whats not working.



  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.