pyscripter

One final remark. If performance is an issue with a "with" statement performance improves to classic levels i.e. procedure MeasureSpring; var i: Integer; begin var s := Shared.Make(TStringList.Create); with s() do for i := 1 to ADD_COUNT do Add(i.ToString); end;

And for the record:

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.

@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.

Could anyone help with this Stackoverflow question?

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.

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:

@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.

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. 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!