Leaderboard

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)

I have just uploaded a beta version of GExperts 1.3.12 for Delphi 10.3 Rio. NOTE: This is a BETA! Beware of bugs, e.g. the Goto-Dialog enhancements cause redraw problems if theming is enabled, the Run Parameters dialog enhancements (drag and drop for files and directories) don’t work at all. https://blog.dummzeuch.de/2018/11/25/gexperts-1-3-12-beta-for-delphi-10-3-rio-available/

Now that Delphi 10.3 Rio is out, we had to ensure that our little mORMot would run with this revision. Since we don't make any commercial software with Delphi any more (we switched to FPC), I downloaded the Community Edition. We disabled the Error Insight feature, which seems not very stable especially with our mORMot complex units - as with previous Delphi versions. In respect to the previous "Starter" editions, this CE version includes everything you expect for good work: Win32 + Win64 + OSX + mobile compilers, and even the source code of the RTL and enabled command-line compilers! The IDE seems really refreshed with its new layout. You feel at home and with some modern and fresh air! Great work Embarcadero! Of course, the "Pro" and "Architect" features are missing (like FireDAC, DataSnap or RADServer). But mORMot is self-contained even for the database access, so with the CE you can write full-features REST/SOA client-servers and MVC web applications, with a simple ORM and high-performance OleDB/ODBC database access to SQlite3, MSSQL, Oracle, Firebird, MySQL and others (by-passing the TDataSet class for better performance) and even NoSQL like MongoDB. Ensure you follow the Embarcadero license terms when you use mORMot with the Community Edition. With Rio, the main breaking change was that the PCRE API switched from an UTF-8 to UTF-16, and did hide the UTF-8 function calls. But after a small patch, now everything works as expected - at least for our regression tests. See http://blog.synopse.info/post/2018/11/24/mORMot-running-on-Delphi-10.3-Rio

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.

My coworkers know my obsession with the tab order in dialogs. I frequently tell them to check it before committing code to the repository (they even released it at some time 😞 ). Now I have to do the same with Embarcadero: https://quality.embarcadero.com/browse/RSP-21726 Why did I notice? Because it broke the GExperts enhancement for the Run -> Parameters dialog. Now I have to change that code yet again.

I had an unfair advantage: A popup menu that did work. So all I had to do was compare them.

You can automate this with Pascal Analyzer: Control Tab Order Report

Yes, it was. I posted my reply, then realized I wanted to quote the message it was replying to. When you hit the Quote button, it opens a new reply. It's not clear how to copy that into an existing reply. So you end up with a duplicate post and no way to delete one of them. I just don't get the point of a policy that simply causes a lot of needless clutter and additional work for people who are already over-worked (Ie., the moderators/admins)

Originally the idea was that the debug dcus only contain additional information for the integrated debugger which should have no performance impact at all. This of course is only true, if all compiler (and possibly linker) settings are equal, which I doubt. E.g. enabling range checking (which I always do for debug builds) can have a significant impact on performance. No idea what the compiler options are in the supplied debug dcus. The jcldebug stack trace does not require debug dcus, but a detailed map file, which does not have any performance impact.

Works well now, compiled for XE7, Tokio and Rio

Hi... W8.1 is like D2005 Show me who doesn't.

really? Why?

Found the cause. It had nothing to do with the Favorites menu. https://blog.dummzeuch.de/2018/11/24/found-the-cause-of-the-av-on-exiting-the-delphi-ide/

If you like my Forms Humanizer for Delphi IDE, I have something new for you and other colleagues. It's a new free plug-in for Delphi 10.2.3 IDE, which shows the status of opened files in the form of colored bars in the tabs above the editor: If you are interested you can download and test it here: https://sites.google.com/site/kryvich/kryvichs-editor-status-bars It is interesting that as follows from the article "New in 10.3: IDE UI Improvements in the Main Window", an appearance of the file tabs in the new Delphi 10.3 will change significantly: