Stefan Glienke

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.

Keep in mind that I have a dict<int, int> so all I do is hash an integer - so the overhead of each gethashcode call is significant for the overall result. If I would hash like some larger data the overhead shrinks - that's what I mentioned earlier about benchmarks and comparing things 🙂

Still like >20times slower than using the one from your xxHash32 unit. THash.TransformUntyped has huge overhead with that dynamic array and the implicit finally associated with it and probably way more stuff going on while the TxxHash32.CalculateHash32 only works with some variables on the stack. BTW for the xxHash32 unit: at least the Delphi compiler will never ever inline RotateLeft32 as the body comes after the call and in such situations it never inlines (see http://docwiki.embarcadero.com/RADStudio/Rio/en/Calling_Procedures_and_Functions_(Delphi)#Using_the_inline_Directive)

@Ugochukwu Mmaduekwe I am probably doing it wrong but using either TMurmurHash3_x86_32 or TXXHash32 in a dictionary equality comparer for integer performs super poor compared to either the THashBobJenkins.GetHashValue from the RTL or the FNV1A_Hash_Meiyan from FastCompare. That is obviously because of the rather heavy OOP architecture which causes several (virtual) calls and allocations for every Compute call. This is what I put into my GetHashCode function for the equality comparer: hash.ComputeUntyped(value, SizeOf(Integer)).GetHashCode; // hash is an IHash instance where I created a TXXHash32 for.

Post the benchmark code please or we are talking apples and oranges.

You missed my point (I blame the language barrier): I was saying that comparing different implementations for some algorithms (such as hash tables) are not trivial to benchmark and compare - I have seen (and written before I knew better) too many biased benchmarks testing only fractions, ignoring certain aspects, using specific data, simply comparing apples and oranges or last but not least being fooled by hardware effects like branch predictors or cache behavior. And that is regardless the programming language.

Implementing a fast hash table has way more and more important implications than picking the proper size and grow factor. Oh and proving that something is faster than another thing is far from trivial (as with most benchmarks). Interesting read: https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/

Worthless, they give a crap about win32 codegen. There are way more severe issues open for ages...

The capacity implementation of the RTL dictionary is a bit stupid. Typically the capacity is the number of items you can store in a collection without a reallocation/grow happening. However that is not the case here (in Spring4D we actually implemented it that way - so if you want to store 100 items without a grow happening you pass capacity 100 - the internal mechanism handles overallocating to satisfy the max fill factor). The RTL implementation takes the passed value, calculates the next power of 2 greater than the passed value, allocates as many buckets and sets the grow threshold to 75% of that value. In the benchmark code above that means from the passed 200 it calculates 256 and sets the threshold to 192 which means you can store 192 items before it will grow.

I am not stopping anyone from exploring that area and I would be happy if someone comes up with a solution. However the way that Delphi, the IDE and the common UI frameworks work imo stands in the way of something that I would consider a good solution. Imho two key parts of MVVM are the painless bindings and the declarative approach to specify the wiring. In WPF most of the wiring goes into the xaml and much of that can be validated and does not rely on magic strings as it does with current solutions in Delphi. MVVM frameworks/libraries in JS can go further and elegantly be integrated into the html code (such as Knockout.js or Aurelia). Then if that is not enough reactive programming pushes such approaches even further as you can see with ReactiveUI and others. While we have event handlers in Delphi the implementation of them is typically done very differently from that reactive does (treating events as a kind of stream of events where you can apply all kinds of operators and behavior)

Especially with the non highly optimized hash functions used in System.Generics.Defaults.

Actually especially for a hashtable that algo is really terrible. It makes it super vulnerable against a non optimal hash function or heavy occurency of hash/bucket collisions. Mod or anding with capacity-1 provides a better distribution.

I have been guilty of doing that myself but given this and other examples it shows why calling virtual methods from a ctor is considered a code smell by some people. And from what I just learned C++ even refuses to do a virtual call as per https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors And also "Injection Constructors should be simple"