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?
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.
"a simple recompile should be all that is needed" ... Unless you use lots of win API's and run 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.