pyscripter

And for the record:

Quote

ADD_COUNT: 100  CREATE_COUNT: 100000
      Spring Shared:699
               Jcl: 648
           Classic: 637
     TSmartPointer: 752

As pointed out In another post by @Primož Gabrijelčič, in Delphi Rio you can just write:

  var s := Shared.Make(TStringList.Create);

What an amazing hack Shared is!  Also impressive type inference from Delphi.

Marco Cantu presented in CodeRage 2018 an implementation of Smart Pointers based on generics, similar to the one found in Spring4D. 

It can be used as follows:
 

var
  smartP: TSmartPointer<TStringList>;
 begin
   smartP := TStringList.Create;
   smartP.Value.Add('foo');
   TStringList(smartP).Add('foo2');

I am using in my code a non-generics implementation from JclSysUtils

var
  sl: TStringList;
  slSafeGuard: ISafeGuard;
begin
  sl := TStringList(Guard(TStringList.Create, slSafeGuard));
  sl.Add('foo'):

The second has the advantage that you do not have to use the Value property to get the object at the cost of having an extra declaration and being less elegant (?).   

Are there any performance or other advantages to the Generics implementation?  Isn't the non-generics implementation faster and doesn't it generate less code?

@John KouraklisToo many to mention.

I don't have such an issue here with default settings and complex Vcl projects loaded.

This is a very promising change in Windows.  However right now it breaks many things including Excel addins.

Never mind.  I found the answer.  If you want to find out how to monkey patch a strict private class method (function) in a way that works in both Win32 and Win64 have a look at the above link.

Could anyone help with this Stackoverflow question?

@dummzeuch I checked again and without debug dcu's you do not get line information for vcl and rtl routines in the call stack, when using jcl debug.  This was the reason I was using the "debug dcus" option.

Ctri+H works fine for me.  If then I select Editor Experts or press E I get what is shown by @David Hoyle above.

If you are using Regular Expressions in Delphi you may want to vote for this https://quality.embarcadero.com/browse/RSP-21733.

JIT can make a huge difference in PCRE performance.

When I use the GExperts. Editor Experts menu command there is no submenu.  A popup menu appears in the editor blank (with no visible entries).

At least we can conclude that the problem with debug dcus is confined to the RE units in win32.  Bug report submitted.

@Attila Kovacs Is the debug built using the "Use Debug dcus" option?

But here I am comparing the same app with/without debug dcus not between 32bit/64bit. 

Actually I just noticed that the difference only appears with 32 bit in Delphi Rio.   Debug dcus make little difference in Rio 64bits or in Delphi Tokyo

The surprising thing is that in this benchmark application, most of the computational time is spent inside external c code linked into the application.   Could it be that the debug dcus link to different c code in 32 bits Rio compared to dcus without debug info?

Another finding was that in Delphi Tokyo, the benchmark runs significantly faster in 64bits than 32 bits  (quite the opposite with Davids zlib experience).

@David Heffernan Please find attached my RE Benchmark application.  Small console app, with the testing text file.  With debug dcus run time increases from 8 to about 14 secs.

RE_Benchmark.7z

Another minor issue I can live with is that the Editor Experts popup menu appears blanc with the Dark scheme.

I used to think that activating the compiler option "Use debug dcus" had minimal impact on performance.  I hadn't done any benchmarking but from experience I could not tell the difference in performance.  So I would include debug dcus even on release versions, so that full stack trace information would be available.   But in my recent tests regarding the performance of Regular Expressions, I found that activating this option would increase run times by as much as 70-80%.  

• Does anyone has done any benchmarking or have any rough idea about this? 
• Is the large performance hit specific to this case? 
• Can you still get full stack trace information without using debug dcus?   (I am using jcl's Debug expert for exception reporting, with jdbg info linked into the executable).

Example stack trace:

PCRE, the regular expression engine used in Delphi has a large number of compile time options only few of which are exposed in the high-level (System.RegularExpressions) or the low-lever (System.RegularExpressionsCore) Delphi interface.  For example a useful PCRE option that is not exposed is the PCRE_UCP, which controls the meaning of \w \d etc.  When this options is set for example \w matches any Unicode letter or _ character.  If it is not set (in Delphi usage) it only matches ascii letter characters.   Class helpers can come to the rescue again.

uses
  System.RegularExpressionsAPI,
  System.RegularExpressionsCore,
  System.RegularExpressions;

type
  { TPerlRegExHelper }
  TPerlRegExHelper = class helper for TPerlRegEx
    procedure SetAdditionalPCREOptions(PCREOptions : Integer);
  end;

procedure TPerlRegExHelper.SetAdditionalPCREOptions(PCREOptions: Integer);
begin
  with Self do FPCREOptions := FPCREOptions or PCREOptions;
end;


type
  { TRegExHelper }
  TRegExHelper = record helper for TRegEx
  public
    procedure Study;
    procedure SetAdditionalPCREOptions(PCREOptions : Integer);
  end;

procedure TRegExHelper.Study;
begin
  with Self do FRegEx.Study;
end;

procedure TRegExHelper.SetAdditionalPCREOptions(PCREOptions: Integer);
begin
  with Self do FRegEx.SetAdditionalPCREOptions(PCREOptions);
end;

Example usage: 

Var
  RE : TRegEx;
  Match : TMatch;

begin
  RE.Create('\w+');
  RE.SetAdditionalPCREOptions(PCRE_UCP);  // No match without this
  Match := RE.Match('汉堡包/漢堡包');
  if Match.Success then
    ShowMessage(Match.Groups[0].Value);

One of the improvements in Delphi Rio is the upgrade of PCRE to version 8.42 and more importantly the inclusion of UTF-16 support on Windows.  What this means is that Delphi strings are no longer converted to UTF-8 and back when using Regular Expressions.  This blog post describes a benchmark of various regular expression options.   I wanted to see the impact of the Rio improvements and here are the results.   The results below use the test suite of the above mentioned article.

Delphi 10.2:  Total Time:    12639.00 ms

Delphi 10.3:  Total Time:    10614.00 ms (about 17% faster)

Further improvement can be achieved by using PCRE Study.  Fir a bit of extra compile time you have significant execution benefits.  You need a class helper to use Study with TRegEx:

type
  TRegExHelper = record helper for TRegEx
  public
    procedure Study;
  end;

procedure TRegExHelper.Study;
begin
  with Self do FRegEx.Study;
end;

You can call study after TRegEx,Create. Here are the results with Study.

Delphi 10.2:  Total Time:    9863.00 ms

Delphi 10.3:  Total Time:   7895.00 ms    (about 20% faster)

Look at https://gitlab.com/teo-tsirpanis/gold-parser-Lazarus for a version 5 compatible Gold engine.  Version 5 grammars are not compatible with versions 1 engines.

But IMHO the good old lex/yacc https://github.com/RomanYankovsky/ndyacclex can be more easily integrated with your Delphi projects.   No need to rely on third party libraries.  One could develop and test the grammar with GOLD I suppose and then translate it to lex/yacc.

Please excuse my ignorance.  What is "New.Of"?

See Marco's blog post.

From the documentation: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/64-bit_Windows_Application_Development. 

Making Your Components Available at Design Time and Run Time
Following are the two ways the IDE decides whether or not a component is available for each platform. (Here "available" means appearing on the palette, and checked by the IDE. The IDE does not do any compile-time checking other than verifying the existence of component unit.)
Both methods described here rely on data embedded in the Win32 run-time (or design+run-time) package that implements the components. The IDE cannot load packages built for platforms other than Win32 in the IDE, so the IDE must defer to the Win32 package for information.

• The RAD Studio build system automatically embeds an RC_DATA resource in the Win32 package binary named PLATFORMTARGETS, which is a bitmask of the pidXXX constants in System.Classes.pas and reflects the package project's targeted platforms. The IDE reads this resource when the package is loaded and uses the resource data to decide, for example, whether or not to disable the component(s) in the palette when an unsupported platform is active.
  Targeting multiple platforms with a component package implies a contract between the component developer and the IDE. The IDE assumes that if a component package project targets multiple platforms and the developer distributes the Win32 run-time package to customers (and all the associated compilable and linkable files), the developer will also distribute all the necessary compilable, linkable, and run-time bits for the other targeted platforms as well.

• Individual components can use the ComponentPlatformsAttribute class attribute to override the data in PLATFORMTARGETS, using a bitmask of the same constants in the Classes unit. For example:
  type

   [ComponentPlatformsAttribute(pidWin32 or pidWin64)] // Only supported on Win32 and Win64
   TMyComponent = class(TComponent)
   private
     ...
   end;

So to get the components to be usable with other plagorms, all you need to do is before you compile the Design package to add the other platform to it. They won't be used but just being there makes the build system to include the appropriate resource flagging the package as usable for the platforms. I have tested this and it works!