Stefan Glienke

So assuming that your code scales linearly it will only take 92 days for 1 billion rows

Looks like nobody ever corrected that statement with the introduction of generics - because then even changes in the implementation section are an interface breaking change. They experienced that themself with the 10.2.2 update where some bug in TArray.Sort<T> was fixed which caused issues so the update was pulled and corrected iirc.

Niklaus Wirth just turned over in his grave about this proposal.

With the exception that ARC is one of the worst ways of doing that - here are some reasons.

This is nothing new - it's called Eytzinger Layout.

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