Stefan Glienke

You might not like it but it's according to the Licenses. Open source does not mean that any modification automatically has to be open and free - that would be the case if choosing MPL.

Maybe because they did not want to look for the problem description within an entire novel? https://en.wikipedia.org/wiki/XY_problem - addressing that is better than giving a solution to what has been asked. Granted the structure and the goal of SO are not well suited for that at times. ChatGPT is like a device that gives you fish whenever you need some but it won't teach you to fish. This leads to the dilemma I wrote about before: maybe it will be the future where all we know is how to ask good questions to our AI that solves the issues for us that we are not able to solve ourselves anymore.

I think we are down to the real issue here: one's own personality. I rather filter out some ego-stroking to get good peer-reviewed advice than some untested garbage but I know people that are already offended when you say: "Sorry, but there is a slight possibility of you being not 100% correct here" (actually meaning: you could not be more wrong). People with a personality like that are usually the ones complaining about SO. I am worried that their solution is using AI-provided help that is completely unchecked and will turn into the software that runs the world in the future.

Just an excerpt from the mormot2 tests (win32, win64 numbers look similar) running on an i7-12700 10.4.2 - Custom RTL: 297,648 assertions passed 285.77ms FillChar in 9.37ms, 41.4 GB/s Move in 22.25ms, 14 GB/s small Move in 25.05ms, 4.3 GB/s big Move in 25.06ms, 15.5 GB/s FillCharFast in 8.21ms, 47.3 GB/s MoveFast in 42.99ms, 7.2 GB/s small MoveFast in 17.15ms, 6.3 GB/s big MoveFast in 26.59ms, 14.6 GB/s 11.3 - Custom RTL: 297,648 assertions passed 247.86ms FillChar in 6.37ms, 60.9 GB/s Move in 10.10ms, 30.9 GB/s small Move in 17.98ms, 6 GB/s big Move in 14.77ms, 26.4 GB/s FillCharFast in 7.37ms, 52.6 GB/s MoveFast in 42.76ms, 7.3 GB/s small MoveFast in 16.83ms, 6.5 GB/s big MoveFast in 27.69ms, 14.1 GB/s The first 4 are RTL functions, last 4 are mormot implementations. Take this with a grain of salt though as these are just unit tests and not a performance benchmark but it gives a little idea. FillChar has already been improved by me for 11.1 and Move will be in 11.3 (along with other improvements in the core RTL) No, this is not suddenly making your applications twice as fast but solves the old complaints of FillChar and Move being sooo slow. 😉

Everything but windows uses libc memmove - we can assume they do their job and have optimized it - similar to FillChar which then uses memset. Until Embarcadero gets their sh*t together with their llvm compilers not generating kinda -O0 quality code personally I don't care about Linux performance anyway.

DDuce does not have a TListDataSet (anymore?) it uses TObjectDataSet from Spring4d

Because there isn't (at least not in the RTL) - ChatGPT is making that up (as so often).

Uploaded the latest version - you can download from https://files.spring4d.com/UsesHelper/latest/UsesHelperSetup.zip

https://delphisorcery.blogspot.com/2021/04/testinsight-12-released.html

Uploaded the latest release - 1.2.0.4 - you can download from https://files.spring4d.com/TestInsight/latest/TestInsightSetup.zip

Funny that you name the topic dynamic array not working when in fact you are declaring a const Anyhow this is a known bug at least since 2018 - see https://quality.embarcadero.com/browse/RSP-19816

I wonder what tech GetIt is implemented in that it cannot cope with a bit of workload

It is being used by the compiler generated template code for C++ (see the code above the implementation of CPPFreeAndNil)

Yes instead of 0 it will be vmtAfterConstruction div SizeOf(Pointer)

This

Is that the same Intel that disabled AVX-512 on Alder lake?

Planet of the Firemonkeys?

Already wrote it: https://www.delphipraxis.net/208147-json-serializer-und-guid.html IMO the solution with the converter has the benefit that you don't need to pollute all your classes with these unnecessary attributes. I guess when using the REST unit there is no way to pass a converter to the underlying serializer/reader/write - the entire architecture is a huge clusterf**k.

TGUID contains this field: D4: array[0..7] of Byte; which does not emit typeinfo for its type You can see this with the following code: uses System.Rtti; var ctx: TRttiContext; begin var t := ctx.GetType(TypeInfo(TGUID)); for var f in t.GetFields do Writeln(f.ToString); readln; end. The issue (not specifically for TGUID) is reported: https://quality.embarcadero.com/browse/RSP-27329 Now even if the RTTI would be available it would serialize TGUID in some format that is most likely not desired. However TGUID <-> string serialization should be supported out of the box imo.

The problem within the global begin/end block is special - usually, inline variables are shown in the debugger but with the limitation that the compiler does not emit so-called live-range data for them which the debugger can use to know the locations they are valid for. For example having two nested variables of the same name causes issues with properly inspecting them because the debugger always shows the value of the first (which causes wrong data to be shown) which also has been reported multiple times.

No, just pray the issue gets fixed in your lifetime

No, because the parameterless TObjectList<T> constructor sets OwnsObjects to True. And that is nothing new but also already was the case in the old TObjectList from Contnrs.pas I am glad I can use Spring4D and have several flavors of multimaps at my disposal

It is from my own experience and analyzing generated code in several different scenarios. I have seen the inliner generating like x times more instructions including ridiculous amounts of mov instructions to and from the stack just to inline a harmless little function which it could way better if the inliner and the register allocator would not have been absolute trash. Plus there are "funny" little issues like this: https://quality.embarcadero.com/browse/RSP-30930 Here is an example where inlining creates some ridiculous amount of instructions: https://quality.embarcadero.com/browse/RSP-31720 (which is not caused by auto but the fact that the getter is being marked as inline)

I would never ever turn it to AUTO because that causes the compiler to inline every function that has a size of 32 bytes or less. The inliner of the Delphi compiler is really bad and while one might think that inlining code usually makes stuff better/faster that is not the case and usually (decent) library developers know where to put inline and where not to put inline.

I assumed it would be obvious from the uses