Stefan Glienke

FWIW, such benchmarks should also run in parallel because especially string-related parsing is usually full of heap allocations that can suffer highly in multithreading. I am also sure that @Arnaud Bouchez could join the game and stomp all these libraries into the ground performancewise with mormot

I have not tested it with extensive data, but my first impression was that it is way more snappy. It does not have all the extensive capabilities of VTune, but if it does the important stuff way faster than VTune it's a pro IMHO. I also presume that it works fine with AMD CPUs.

This morning, I started the 14-day trial of Superluminal, and my first impression is very positive. I have yet to run it against more than some tiny toy projects though

No, but according to RFC 8259, they *should* be unique. I just pointed out that by supporting that feature, there needs to be done more than simply adding pairs without any lookup. In fact, it looks like some implementations don't even allow adding duplicate names.

The tests ignore some subtle differences in the implementations. While some implementations ensure that you don't create multiple pairs with the same name the System.JSON AddPair method simply ignores that. You can test that by adding a fLib.Add(SKey, SVal); after the loop in TTestSpeedRun.DoSubTestGen - some libraries will report 50000 items, while some report 50001 - System.JSON for example. The fact that JDO uses a linear search here is a bit disappointing and the reason it completely falls off the cliff on the generate test.

Because Pos is 1-based while SelStart is 0-based. You could have read the documentation: https://docwiki.embarcadero.com/Libraries/Athens/en/System.Pos https://docwiki.embarcadero.com/Libraries/Athens/en/Vcl.StdCtrls.TCustomEdit.SelStart

Yes, no surprise - because const[ref] forces a reference type variable to be passed by reference - build version three of your routines that have their parameter as var, and you will see. Also, your reasoning about what you see is mistaken - if you retrieve the address of a parameter or variable that resides in a register, the compiler will reserve stack space for it to retrieve the address of it. In the case of passing a const string as first and only parameter that one will be passed in eax on 32bit windows, or rcx in 64bit windows - calling @ on that parameter cannot give an address if that parameter stays in the register, hence the compiler generates code to reserve stack space, and puts the value there and retrieves that address.

If you are interested in collaboration: I could use a SIMD function that satisfies the following API: function PartitionRight(lo, hi: PDataType; out pivotPos: PDataType): Boolean; PDataType is the pointer to the type that is being sorted, such as PInteger or PDouble hi is exclusive. The result specifies whether the data has already been partitioned. For a start, a version for PInteger would suffice to run further benchmarks to evaluate if the impact is noticeable enough to justify an asm version The original reference implementation can be found here: https://github.com/orlp/pdqsort/blob/master/pdqsort.h#L329

It works very well for multithreading. You just have to change the sampling mode.

This just underlines that GenAI and copyright is a delicate thing

I don't know what research RDP did (probably asking some GenAI ), but Spring4d does not contain thread-safe collections - for those needs, refer to libraries such as OTL or protect them by primitives in your own code according to your use-cases. I don't step into that territory because you cannot simply make general-purpose collections thread-safe. It already starts with simple things like: how do you protect a list where one thread adds/removes items and another iterates over it? It then requires a different API, and it's complex to design a general-purpose thread-safe collection library because everyone has their use cases, which you cannot simply combine.

As I mentioned in the thread you referred to, this interface no longer exists. But as you might have noticed in the Spring commits in develop, I have my own Span implementation, and IList<T> has the method AsSpan, which returns this.

2024 called and wants its news back

List always does linear search, which is O(n), while hashset does it in O(1) - however, considering the significantly higher cost of calculating the hashcode even with a very fast hash function (which the RTL does not use) and the length of the string for a small amount of entries linear search beats a hashtable. In theory, if the entries are not changed that often, one could sort the list and use binary search. But that also requires a fast, optimized, inlined BinarySearch implementation, which the RTL does not have, IIRC. P.S. Rapid.Generics.TList<T>.IndexOf is broken - line 19503 causes an endless loop. The same defect exists in InternalIndexOfRev. How to repro: procedure IndexOfEndlessLoop; begin var list := Rapid.Generics.TList<string>.Create; for var i := 0 to 1 do list.Add(TGUID.NewGuid.ToString); list.indexOf(list[1]); end;

One thing that I dislike about the Rapid implementation is the ton of magic numbers and the fact that the used hash algorithm is documented nowhere - I assume some form of Robert Sedgewick hash (which I could not find a formal description of anywhere on the internet). That makes it hard to verify its correctness and behavior.