Stefan Glienke

I said this before and I say it again - nobody should care how long the compiler churns on producing a release config build. Also: the FE is still written by Embarcadero and I don't know how much time is spent there compared to the LLVM BE and how much of that could be improved by tweaking some settings. Given their usual attitude of "making it barely work" and leaving optimizing for later until everyone and their cat/dog complains and then waiting even a few years longer until tinkering around the edges I can only imagine how well done the FE is. Also, keep in mind that the Windows compilers regressed heavily with all the new language features introduced in the past 15 years and that it was mostly due to the efforts of Andreas Hausladen that we gained back some of that speed in the recent versions while still being way behind what it could be imo. Currently reading through the thread (not done yet but just leaving my thoughts as I go through) and this comment was interesting: Interestingly later someone comments that if you compile a different project it turns around into the opposite - and then there is this statement: This is something I have actually seen with the non-Windows Delphi compilers: when I throw some generic-heavy code at them they take a ridiculous amount of time to compile - and some of the optimizations done by Andreas Hausladen actually resolved around generics. I would not be surprised if such an issue still exists either in the BE or in the LLVM code when generating debug symbols due to all the long full-qualified type names.

If it at least would produce binaries that are faster than what classic compiler for Windows produces ... But due to their currently super old LLVM version (hopefully they upgrade that once they are done on the C++ side which personally I could not care less about), they apparently had to turn off some important optimization steps which causes the binary produced by the Linux compiler to be approx as good as -O0

The usual reasons for memory leaks that I have seen: - not using interfaces as service types - registered components are not inheriting from TInterfacedObject (or some other properly reference counting implementing class) - in combination with the previous point when using AsSingleton without explicitly stating a value for TRefCounting to tell the container if the class implements ref counting or not - injected dependencies are further passed to and held by other services creating cross or cyclic references (use LeakCheck to better find them than just looking through the huge list that FastMM produces, ideally in a smaller scope, 2GB memleak log sounds a bit huge) You can log some of that information by iterating .Registry.FindAll from the container instance and checking various properties of each TComponentModel such as ComponentType, Services and LifetimeType.

The GetSystemTimes call reminds me of System.Threading.TThreadPool.TThreadPoolMonitor.Execute which calls TThread.GetCPUUsage all the time. See https://quality.embarcadero.com/browse/RSP-43540

Regardless of which of the mentioned package managers you will be using - all will be open to supply chain attacks.

If the compiler optimization was worth a penny it would not matter which way the code was written and it would emit the best version regardless and depending on the situation where this function is being called and inlined - however, the compiler optimization is rather terrible so this might be some poor attempt to optimize for a certain situation where storing in two boolean variables creates less or no conditional jumps opposed to the short circuit evaluated combined expression with two comparisons.

While Wine 9.0 just introduced this feature? Doubt

Check your facts, please https://learn.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems#supported-operating-systems-for-microsoft-edge Fun fact: that already is the case (it even only runs on Windows 11 21H2 or later) - see https://apps.microsoft.com/detail/9MSMLRH6LZF3

Get real - extended support for both ended four years ago. The market share of Windows 7 is at around 3% If you want to support ancient operating systems then use ancient Delphi versions. According to you Visual Studio 2022 (Supported Operating Systems) would be just dead

Do you mean this? https://bitbucket.org/sglienke/spring4d/wiki/Spring4D 2.0 Releasenotes (I think they are not linked from the readme thus easy to miss - I will fix that shortly)

Did you know that LEGO and Michelin are competitors? They both manufacture tires...

That was the point to show how it gives you the wrong one if two interfaces have the same GUID. The interfaces and their implementation in the RTL inherit from each other so their IMT overlap and the implementations don't differ between those two so there is does not matter. Simply try that for yourself by inheriting one of the interfaces in my example from the other.

How some other company monitors their package manager.

RTTI does have nothing to do with it but TObject.GetInterfaceEntry - try the following code: type IFoo = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetFooName: string; end; IBar = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetBarName: string; end; TFooBar = class(TInterfacedObject, IFoo, IBar) function GetFooName: string; function GetBarName: string; end; function TFooBar.GetFooName: string; begin Result := 'Foo'; end; function TFooBar.GetBarName: string; begin Result := 'Bar'; end; var i: IInterface; begin i := TFooBar.Create; Writeln((i as IFoo).GetFooName); Writeln((i as IBar).GetBarName); end. The interesting thing with those two interfaces in the RTL is that coincidentally they will not cause any harm because of how they are implemented and related to each other - the one inherits from the other and they are also implemented by classes that inherit from each other.

Just store Pointer as UInt64 all the time

Reported as RSP-44066

FWIW there is already this issue with 171 upvotes - it explicitly mentions Raspi but that would be a start. Given that Allen Bauer already had some kind of prototype ready in 2015 it's a shame Embarcadero never moved that forward.

I don't know what web finds you are referring to but afair they had been called Initialize and Finalize from the beginning when they were actually released - see https://docwiki.embarcadero.com/RADStudio/Sydney/en/Custom_Managed_Records They initially planned them for 10.3 but they were dropped shortly before because they were even more broken than at the time they got released in the version after - at that time the syntax was different but as said this was never released https://blog.marcocantu.com/blog/2018-november-custom-managed-records-delphi.html

Introducing "Uses Helper" - some little but incredibly helpful IDE plugin https://delphisorcery.blogspot.com/2021/03/introducing-delphi-uses-helper.html

Reported as RSP-44059

Sorry, I meant _ClassCreate - the compiler inserts a call to that routine in the prologue of each ctor. When calling the ctor on a class the compiler passes 1 as the second parameter which signals this routine to call TObject.NewInstance.

You can trick/hack a bit and do what you want to achieve manually: This is basically what a regular ctor call on the class type does (see System._ClassCreate). function TSomeClass<T>.CreateNewInstance: ISomeInterface<T>; var obj: TSomeClass<T>; begin obj := TSomeClass<T>(ClassType.NewInstance); obj.Create(fSomeParameters); Result := obj; end;

The irony about this is that to build a RAD application you are using components that are by design loosely coupled and more or less easily testable in isolation. The issue starts with non-UI-related code written directly into UI control event handlers and accessing global states such as these global form variables. If one would write their RAD application also in a component-driven architecture, things would be way easier - but slapping code into event handlers is quick at first and a nightmare to maintain later.

There is no magic, you implement INotifyPropertyChanged and raise events in setters.

Fixed. You should be grateful that the CE is released at a point where it's the least broken version you can get.