1. Steen Jakobsen
  2. Beta Testing
  3. Tuesday, 21 June 2022 07:36 AM UTC

Hi,

 

PB2022 runs SIGNIFICANTLY faster than PB2019R3

 

We have made a computation index for our application to measure the performance of the machine running it so our customers knows what to expect from our application.

This test include all kinds of scrip execution : loops, dw-find, string manipulation etc.

And the index is 60% faster with pb2022 compared to pb2019R3

 

FANTASTIC - good job Appeon !!!

 

//Steen

 

René Ullrich Accepted Answer Pending Moderation
  1. Tuesday, 21 June 2022 07:43 AM UTC
  2. Beta Testing
  3. # 1

Hi Steen,

Thank you for sharing your experiences.

Do you can be more specific about what kind of scripts are how much faster? Or do you have "only" a general index?

Regards,

René

 

 

Comment
  1. Mark Goldsmith
  2. Tuesday, 21 June 2022 13:25 PM UTC
That's quite a difference! Thanks for sharing your findings Steen. I think Miguel L. did a comparison recently on string replacements and what might the best approach but I don't think it included PB 2022. It would be interesting to see how this version compares with those same tests. Thanks again.
  1. Helpful 1
  1. Roland Smith
  2. Tuesday, 21 June 2022 17:18 PM UTC
32 or 64 bit?
  1. Helpful
  1. Steen Jakobsen
  2. Monday, 27 June 2022 08:04 AM UTC
both
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 21 June 2022 15:04 PM UTC
  2. Beta Testing
  3. # 2

Hi Steen;

  FYI: One of the main reasons is that Accessibility is now OFF by default (As mentioned in the PB 2022 Help).

Also ... locate the Initialization Path in the System Options dialog of the IDE. Then use File Explorer on that location to open the PB.ini file. In there, you will find the setting Accessibility=0 is now set as the default.

Regards ... Chris

Comment
  1. John Fauss
  2. Tuesday, 28 June 2022 17:42 PM UTC
You deploy a much smaller pb.ini file with the app that contains only the settings needed by the application. The PB runtime environment looks for this file every time you start a PB application.
  1. Helpful 1
  1. Steen Jakobsen
  2. Thursday, 30 June 2022 07:44 AM UTC
Chris,



It is not the case with accessibility in my tests, as it is turned off by me.

So in my view, the performance improvement is purely PB2022 it self not the accessibility.



Great work Appeon.



Thanks :-)
  1. Helpful
  1. Chris Pollach @Appeon
  2. Thursday, 30 June 2022 15:40 PM UTC
I also suspect that the better performance is because PB2022 is compiled with a newer VS C++ compiler. ;-)
  1. Helpful 1
There are no comments made yet.
Ankur Patel Accepted Answer Pending Moderation
  1. Wednesday, 29 June 2022 13:43 PM UTC
  2. Beta Testing
  3. # 3

Hello All,

 

Just for everyone's information. Here is the string operation slowness bug that I reported: https://www.appeon.com/standardsupport/track/view?id=7255 it has the details of string operation comparison between PB 11.5, PB 2019 and PB2022 using the Roland's freecode_stringclass. In summary, string operations were fast in PB 11.5 then slowed down in PB 12.6 and now in PB2022 they are even faster than PB 11.5. So Appeon developers have done a great job on this.

 

Comment
  1. mike S
  2. Wednesday, 29 June 2022 13:50 PM UTC
great to hear details on performance enhancements!
  1. Helpful
  1. Steen Jakobsen
  2. Wednesday, 29 June 2022 14:33 PM UTC
awesome :-)
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 30 June 2022 06:02 AM UTC
  2. Beta Testing
  3. # 4

Hi,

See: https://community.appeon.com/index.php/qna/q-a/use-c-for-replace-function

As suggested by Mark Goldsmith, I've compared my timings of PB2021 with PB2022. Quite interesting!

Pb2021:

f_str_replace: 352.703 seconds. (point as decimal separator)

PFC- Mid() (of_globalReplace): 203.922 seconds

Roland's BlobMid() solution: 134.453 seconds.

Dotnet_replace C# DLL: 0.015 seconds.

 

pb2022:

f_str_replace: 117.9 seconds. (point as decimal separator)

PFC- Mid() (of_globalReplace): 172.6 seconds

Roland's BlobMid() solution: 26.5 seconds.

Dotnet_replace C# DLL: 0.031 seconds.

 

Conclusion:

In pb2022, f_str_replace is now more than twice as fast and even outruns the PFC Mid() based of_globalReplace function !!! Maybe something we could consider when doing any PFC improvements! The PFC replace has also improved, but not as much and no longer remains a better solution than a normal Replace().

Roland's stringclass BlobMid() based solution has improved enormeously too! Very impressive.

Interesting enough, though still the fastest, the DotNet replace has doubled time execution: from 0.015 to 0.031 seconds.
With PB2021, I would only get 0.031 seconds when using a DLL that was compiled for "any cpu". Now the x86 compilation is just as slow in pb2022.

regards,

MiguelL

 

Comment
  1. Miguel Leeuwe
  2. Friday, 1 July 2022 04:40 AM UTC
Hi Steen,

Don't forget. It's only faster when doing a lot of search and replace within a string, which as for now requires us to do looping. For a single Replacement in a 'normal' length string, PB's current replace is perfect! I've requested a ReplaceAll() function to Appeon though, where something like that would definitely give us a lot of gain, be it in C, C++, ASM or C#.

Regards.
  1. Helpful 1
  1. Mark Goldsmith
  2. Sunday, 3 July 2022 19:19 PM UTC
Thanks again Miguel for taking the time to do these comparisons with PB2022. Interesting results, in particular with Roland's BlobMid() having an 80% reduction. This is very helpful information!
  1. Helpful
  1. Miguel Leeuwe
  2. Monday, 4 July 2022 07:48 AM UTC
Yw Mark, it's the least I can do for all the great support you give us!
  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.