Stefan Glienke

FToollist is certainly not being freed but the items because the list returned by FindAll has OwnsObjects = True and goes out of scope at the end of the method. Write dm.Session.FindAll<TTool>.MoveTo(FToolllist);

I would like to but I don't (and not because of FUD but because I know of the bugs myself) - do I need to say anything more? Ask around in other languages if people in general trust their compilers and standard runtime libraries or not.

https://en.wikipedia.org/wiki/Hyperbole

Dynamic arrays cannot leak unless you circumvent the compiler generated code controlling their reference counting.

FWIW just recently my coworker opened these issues that are related to this topic: https://quality.embarcadero.com/browse/RSP-27799 https://quality.embarcadero.com/browse/RSP-27802

VS is also not perfect but their compiler and language design is rock solid - yes, if you look into C# communties there are also people complaining that stuff is not C#-ish and that but the number of times where the C# compiler just craps itself, kills the entire IDE or simply produces completely wrong code is like several orders of magnitudes less than with Delphi.

YES, exactly that! However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape. Like using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords or introducing inline variables (that had many bugs) without the entire tooling understanding them and stopping to work. So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff"

Interesting - even with {$mode delphi} it does not allow that - probably it's yet another of those bazillion switches of FPC to make it behave similar to Delphi - not that I would ever care. Anyhow this is still a thread about Delphi so your approach is not sufficient here imo. @Fr0sT.Brutal It's a little less simplistic than that but basically yes.

As I wrote before a final method or sealed class will produce a non virtual call in your approach - try again the code from your original post with virtual in TTest1 and override final in TTest2. Also let me add that the fear of virtual method calls is way too high and in most cases it turns out they don't affect the overall performance at all (especially not with some code that the Delphi compiler produces that trashes your performance in other ways) If you call a virtual method in a tight loop and want to avoid the "virtual method address lookup" (again, measure if it really affects anything) that happens every time then you can store it as a method pointer before and then call that one in your loop.

Then you probably should read them again - they say: warning CS0114: 'TTest2.Test()' hides inherited member 'TTest1.Test()'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.

public new is not overriding - that's similar to reintroduce - if you want to override, you write *drumroll* override I would even guess the CLR to be clever enough to devirtualize it entirely

You make the Test method virtual just like was suggested in the 2nd post for the similar Delphi code. You can then even make the override in TTest2 final or make the class sealed and get a non virtual call generated by the compiler!

How about you write the code in a proper way: using System; public class TTest1 { public void Test() { Console.WriteLine("TTest1.Test"); } } public class TTest2: TTest1 { public void Test() { Console.WriteLine("TTest2.Test"); } } public class TTest<T> where T: TTest1, new() { public static void TestIt() { var FTest = new T(); FTest.Test(); } } public class Program { public static void Main() { TTest<TTest2>.TestIt(); } } The reason FPC does it different is because its generics are behaving more like C++ templates. However for generics there is no kinda "duck typing" or prototyping. You tell the generic class "look there is the type parameter T, which is guaranteed to be a TTest1 and it has a constructor". So when the compiler generates the AST for the generic type it just takes from these informations and so it decides to emit a static call to TTest1.Test because that is not a virtual method. This is the behavior in all languages with generics that I know of (such as C# or Java) - languages that use a templating approach such as C++ and possibly FPC does it similar decide what to call when the type parameter is being specified. Generics in this case behave the same way as if you would write code like this: procedure TestIt(const t: TTest1); begin t.Test; end; here it will always call TTest1.Test and not TTest2.Test even it t is a TTest2 - simply because there is no polymorphism happening due to the lack of a virtual method call. Personally I would rather call this a bug in FPC - but again it depends on the actual language specification/implementation. Both have their pros and cons. I cannot find the official specification for generics in FPC about this specific point to verify.

That is nullable reference types which is a completely different beast and took the compiler and language guys at Microsoft a significant amount of time to get it right.

Not typesafe, thank you bye.

Unfortunately what was great in 2003 might not be anymore because hardware evolved. However what is true is that once the contiguous array passes a certain size the memory will be across multiple pages anyway and then it does not matter much if it were not contiguous - only the calculation of the index needs to be as fast as possible.

What you describe could avoid memory reallocations and moving items if reallocation could not happen inplace but has a lot of other performance considerations - see https://softwareengineering.stackexchange.com/questions/267870/are-noncontiguous-arrays-performant

RAD Studio itself is the best example: system enhanced is far superior to its own scaling - minus the blurry text in the code editor (which could easily be fixed by drawing on compatible bitmaps instead of DIB) This is no new knowledge: https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/

Data please or I call that fake news

There is a bug somewhere within the thread pool - I have experienced a similar behavior where the thread pool creates more and more threads and they somehow leak somewhere and only exit when the application closes but are not reused to execute tasks. If I remember correctly it has been reported before and is being worked on - I just cannot find the exact number on QP.

You will find information on google if you look for how to make queries and charts in jira.

No need to export anything - JIRA has excellent charting - examples:

As for the publicly reported issues you can easily put that together yourself on the quality portal (JIRA) dashboard.

Thank you. I am just trying to put test results into perspective (*) - just posting some numbers is almost useless until one knows what was tested. That's all I wanted to know. Especially when then people compare different hash algorithms based on how much throughput they have for large data - which is interesting but almost irrelevant for hashtables. (*) Reason is I am still evalutating if it might be worthwhile to also drop System.Generics.Defaults from Spring.Collections and roll our own comparers with more optimized code.

Well technically for all use cases of a hash function for a hash table unless the data you are building a hash for is super large (which is rather rare I think) - which is what this topic started with. Anyway that is why I asked FredS for his benchmark code to be able to compare the same things.