Leaderboard

Short answer: Use Parallel.For. Long answer: Parallel.ForEach was written not for parallel processing of integers but for parallel processing of any weird kind of data. Because of that it is overly complex and not good for simple (for i in range) cases. It is usually about 10x slower than PPL's TParallel.For. That is why I later wrote Parallel.For, which works only on integer ranges and is on par with the PPL implementation.

I can absolutely repro - all my 20 logical cores (i5-13600k) go to 100% for 10 seconds. Running it through SamplingProfiler right now to check. Edit: Okay, either this has regressed at some point after the demo was originally built or it was overlooked that there is actually no real workload inside of the delegate and thus it just measures the huge overhead from RTL and interlocked operations. It's just spending a huge amount of time wrapping and unwrapping the integer from TOmniValue and sharing the counter across all threads causing a complete bus lock every time due to the usage of DSiInterlockedExchangeAdd64 (*). (*) I wrote bus lock and this is not entirely true, so before anyone chimes in quoting the Intel manual about the fact that the lock prefix does not automatically cause a bus lock - you are correct. Here we have the case that we are sharing the one variable across all the cores we have so it has to travel back and forth the CPU caches to and from RAM. This code as is would be a nice worst-case example for Primoz' book about what can potentially go wrong when doing parallel programming. However: keep in mind that we don't have any real workload which would most likely change the picture as the workload usually takes the majority of processing time and not the parallel foreach code. P.S. Among the aforementioned things it looks like the OTL code (particularly TOmniValue) is suffering from some overhead caused by inlining. For example: because TOmniValue.AsInt64 as well as TOmniValue.TryCastToInt64 is inlined it causes the temporary Variant variable it needs for the otvVariant case to be spilled into the location where the inlining happens. But in our case we never have to even deal with a Variant hence all the extra code the compiler produces is just overhead. And because the getter for AsInt64 is used twice, the compiler repeats the inlined code twice and produces two Variant variables which it finalizes using System.FinalizeArray. Also a lot of record initialization and finalization is happening which I assume (did not look closer) is being caused by TOmniValue - potentially also because of some temporary compiler generated variables. Here is the drilldown of the interesting pieces when running in SamplingProfiler:

ICS V9.2 has been released at: https://wiki.overbyte.eu/wiki/index.php/ICS_Download ICS is a free internet component library for Delphi 7, 2006 to 2010, XE to XE8, 10, 10.1, 10.2, 10.3, 10.4, 11 and 12 and C++ Builder 10.4, 11 and 12. ICS supports VCL and FMX, Win32, Win64 and MacOS 32-bit targets. Beware Mac OS-X and C++ have not been tested recently due to lack of support from such users. The distribution zip includes the latest OpenSSL 3.0.14. 3.2.2 and 3.3.1, for Win32 and Win64. Changes in ICS V9.2 include: 1 - V9.2 is a minor release, fixing a few issues introduced in the last major release, and other bugs located since. There are no breaking or installation changes from V9.1, but if updating from earlier releases please read https://wiki.overbyte.eu/wiki/index.php/Updating_projects_to_V9.1 2 - TIcsMailQueue can now queue a prepared EML file created by another application, or perhaps received by the SMTP Server. Added optional SkipEmpty argument to StartMailQu method so queue is not started unless there are pending emails waiting to be sent. The sample has 'Send Prepared EML File' to queue an existing EML file rather then preparing email with properties. 3 - Improved email MIME decoding by supporting embedded boundaries, usually for multipart/alternative parts, within a multipart/mixed message, using code written 20 years ago but suppressed for some reason. Previously these parts were sometimes left encoded within a part. There is a new property LooseRFC to allow decoding if the boundaries in the body are missing the two required hyphens, usually because the boundary also begins with hyphens. TMimeDecodeEx should now always return the body if no MIME parts are found, and TPartInfo has PLevel which is Part Level, and PInfo which is displayable part information for logs. The MimeDDemo sample has various improvements to test these features. 4 - Fixed a nasty Win64 problem reading EC certificates from the Windows Store, which may have caused server crashes, also reproducible in the PemTool listing the Windows Store. This was due to Win64 bad initialisation of a buffer used for a Crypto API call that failed. 5 - The HTTP client now checks the URL always has / at start of the path, ie add it for test.com?query. In the REST client, added a sanity check for RawParameters to encode any spaces, which can break the HTTP request. After a file download completed, check actual file size against response size. The multipart/form-data MimeBoundary no longer includes extra -- at start that are required preceding boundaries within parts, some web servers may have been unable to decode our MIME encoding. 6 - The HTTP server has a new method AnswerRedirect for various redirection responses to a new URL. When accessing the default document in a path without a trailing path delimited /, redirect using 301 to the correct path with delimiter instead of adding it locally and displaying the document which will then incorrectly link to pages in a higher level directory. Using the THttpOption hoAddMissPath redirects if the default document is missing perhaps a template or virtual document. Fixed a bug where authenticated POST/PUT requests always returned a 404 error. Added AnswerBodyTB client response with TBytes binary, similar to AnswerString, tested in the sample by supporting favicon.ico request. Check if the request HTTP version gets corrupted due to spaces in the URL, which are not allowed. The SslMultiWebServ sample has new web pages to test POST/PUT and template authentication. 7 - TSslX509Certs has a new function CertResetDomain to reset a certificate order state to None, if the order process stalls or gets confused due to errors. If AcmeV2StartChallgs fails because there are no pending challenges, reset to order to None so it starts again next time and does not loop. 8 - ICS not longer tries to load OpenSSL RAND_screen function that may be missing from recent DLLs. 9 - TIcsHttpMulti fixes a bug introduced in V8.66 that stopped the application setting authentication, rather than adding it to the URL, and a Win64 free stream bug. 10 - TIcsIpStrmLog correctly counts failed client connection attempts if ping is not used first to check the remote IP address. The sample has a new client Retry Attempts box to test this. 11 - Updated the Snippets sample to use authentication to access some the hardcoded URLs, which started failing after authentication was added to test web server bugs (see above). 12 - Added OverbyteIcsHttpThrd sample to show how to use TSslHttpRest component in a multi-threaded program. 13 - Improved Posix support for Linux and Android, not tested or supported yet. Beware SSL does not correctly load for Posix at the moment. 14 - Added support for a new feature release of OpenSSL 3.3 with {$DEFINE OpenSSL_33} in the Defs.inc file, ICS includes new versions of the active versions, 3.3.1, 3.2.2 and 3.0.14, but no longer includes 3.1 since there are two newer feature versions. 15 - Updated the 'ICS Intermediate Short' SSL certificates, used by ICS to generate temporary server certificates to allow SSL servers to run until a Let's Encrypt or commercial certificate is installed. It now expires after 200 days, 21st December 2024, after which self signed certificates will be used instead, unless a newer 'short' is installed. 16 - Only Delphi 10.41 and 10.42 (10.4 with updates 1 or 2) will install correctly with the new install packages, the original RTM version does not support the package LIB suffix: $(Auto) so you must change it manually for each package to 21.0. The release notes for V9.2 are at https://wiki.overbyte.eu/wiki/index.php/ICS_V9.2 All ICS active samples are available as prebuilt executables, to allow ease of testing without needing to install ICS and build them all. There are four separate zip files split into clients, servers, tools and miscellaneous samples which can be downloaded from https://wiki.overbyte.eu/wiki/index.php/ICS_Samples Angus

The plethora of working Delphi programs are proof that there already exist concepts to eliminate dependencies between units. They may differ from those available in other programming languages, though. IMHO, circular dependencies should be eliminated even if they appear in implementation sections and thus making the code compile. I wouldn't support any request to extend that in any way leading to more circular dependencies.

Currently I am trying to use "TTestDataProvider" to provide my test cases with test data. However, in the following example, I have encountered a memory release problem that I cannot solve myself. The destructor of the "TObjectProvider" class seems to be called before the actual test run: unit UTest; interface uses DUnitX.TestFramework, DUnitX.InternalDataProvider, DUnitX.Types, Generics.Collections; type TTestObj = class Name: string; end; TObjectProvider = class(TTestDataProvider) private type TTestData = record Name: string; Data: TTestObj; end; var FList: TList<TTestData>; public constructor Create; override; destructor Destroy; override; function GetCaseCount(const AMethodName: string): Integer; override; function GetCaseName(const AMethodName: string; const ACaseNumber: Integer): string; override; function GetCaseParams(const AMethodName: string; const ACaseNumber: Integer): TValueArray; override; end; type [TestFixture] TMyTestObject = class public [TestCaseProvider('TObjectProvider')] procedure TestObject(const AValue: TTestObj); end; implementation uses SysUtils, Math, DUnitX.TestDataProvider; { =========================================================================== } constructor TObjectProvider.Create; var Item: TTestData; begin inherited; FList := TList<TTestData>.Create; Item.Name := 'Testobject 1'; Item.Data := TTestObj.Create; Item.Data.Name := 'Testobject.Name 1'; FList.Add(Item); Item.Name := 'Testobject 2'; Item.Data := TTestObj.Create; Item.Data.Name := 'Testobject.Name 2'; FList.Add(Item); end; { =========================================================================== } destructor TObjectProvider.Destroy; var item: TTestData; begin for item in FList do //<-- Remove me to succeed but leak the objects FreeAndNil(item.Data); //<-- Remove me too. FreeAndNil(FList); inherited; end; { =========================================================================== } function TObjectProvider.GetCaseCount(const AMethodName: string): Integer; begin Result := FList.Count; end; { =========================================================================== } function TObjectProvider.GetCaseName(const AMethodName: string; const ACaseNumber: Integer): string; begin Result := Self.ClassName + '[' + FList[ACaseNumber].Name + ']'; end; { =========================================================================== } function TObjectProvider.GetCaseParams(const AMethodName: string; const ACaseNumber: Integer): TValueArray; begin SetLength(Result, 1); Result[0] := FList[ACaseNumber].Data; end; { =========================================================================== } { TMyTestObject } procedure TMyTestObject.TestObject(const AValue: TTestObj); begin Assert.IsNotNull(AValue); Assert.IsNotEmpty(AValue.Name); end; { =========================================================================== } initialization TestDataProviderManager.RegisterProvider('TObjectProvider', TObjectProvider); end. Can anyone give me a tip on how to solve this problem?

CrossPost

Nice insights! I'll make some updates once I managed to set my dev VM up (I'm in the middle of switching to Linux on my daily driver atm...)

Browsing the code i have thoughts 1) from SendInput https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput 2) This class TAEKeepMeAwake is somehow asynchronous, in other words it has its own timer and doesn't depend on application logic to be triggered or executed, it depends on OS timer, so when things go wrong that exceptions raising RaiseLastOSError, might cause havoc like endless messages every 1 second. 3) I hate raising exception specially if they are not needed, and in this case its like : ok, let some other part of the application handle this, here take an exception,... Exceptions are not signaling mechanism, notice here with (the mentioned above function) the exception will be generic and useless, and if the application error reporting failed to capture the stack, then application might end up showing funny messages like "exception was caught.. last error (or last operation) was success". I would suggest to remove exception raising and replace them with OnError event, in my opinion this is less intrusive method and more useful (less ticking bombs), also this class and before calling such event it should disable its timer, leaving the decision to reenable the developer. Sorry if Off-topic.

I have a component which detects and attempts to "break" the idle status. https://github.com/aehimself/AEFramework/blob/master/AE.Comp.KeepMeAwake.pas Works fine even in remote desktop connections.

Only if you don't make use of Change Views. AFAIK, it also lacks Column-level Encryption.

Yes. See this link.

auto close or logout when no mouse activity - VCL - Delphi-PRAXiS [en] (delphipraxis.net)

If videos are in the game, a lot of things are available on Embarcadero's YouTube channel : https://www.youtube.com/@EmbarcaderoTech/playlists Look at (the old) "modernize with Windows 10" playlist : Or the "Desktop First UX" During the online conferences some speakers had shown a lot of things about FireMonkey and designing programs. One of them (Ray Konopka) is a specialist of this subject : https://www.youtube.com/@EmbarcaderoTech/search?query=konopka And if you want to understand how FMX and the IDE work together, you also can be interested by my (in English) videos from last year conference : From GetIt you'll find some screen samples, it could be an help to design and understand how to stack components to reproduce the beautiful UI you (or your infographist) have in mind. 😉

Refind is quite capable to help to migrate other components not only FireDAC.