Stefan Glienke

The main reason is in the very first sentence of my previous post. Also as you are so into benchmarking I suggest you make yourself familiar with profilers so you don't have to guess or ask others what is taking time as you can very well see for yourself.

Which does absolutely nothing since like XE7 or so when they fixed the $RTTI switch to be local to the current unit.

This cannot be because XE already had extended RTTI. It's more likely that internal refactorings of the RTL and VCL such as using generic lists instead of good old Classes.TList and Contnrs.TObjectList contributes to the bloat. Of course with RTTI being enabled on those lists it leaves all the typically inlined method calls in the binary. I wonder what difference {$WEAKLINKRTTI ON} would have.

52^6 is bigger than 32bit so of course a 32bit RNG might not yield it. In fact its over 4 times more than 32bit so only like every 4th possible 6 letter combination would ever be yielded. Bonus hint: try a lowercase d 😉

Because IComparer<T> created via TComparer.Construct (TDelegatedComparer<T>) suffer from this issue: https://www.idefixpack.de/blog/2016/05/whats-wrong-with-virtual-methods-called-through-an-interface/ Furthermore every call to GetName_TArrayBinarySearch constructs the comparer again. Eliminating that as well gives me a result of 159 vs 105 which then can be explained by the additional calls through IComparer<T> and the probably a little less optimal allocated registers in the actual method that performs the search because that is the one with many more arguments in class function TArray.BinarySearch<T>(const Values: array of T; const Item: T; out FoundIndex: Integer; const Comparer: IComparer<T>; Index, Count: Integer): Boolean; FWIW your implementation is not exactly the same as the RTL one as you exit as soon as you find a match while the RTL implementation because it returns the index goes on because it returns the first index in case there are successive elements matching.

If you mean accessing the TList<T> as an IList<T> without moving the items from one list to the other - youll need to write an adapter that wraps the TList<T> into an IList<T> - library does not contain one. If you mean to move the items then you need to loop or use .ToArray on the TList as the IList interface does not offer any overloads accepting a TList<T> or TEnumerable<T> from System.Generics.Collections and that will not change.

Last time I checked this was a Delphi forum, so no clue if php can do this and the API can very well be not 100% adhering the spec - but an array with a null in json would be [null] Anyway none of that relates to your initial question imo - all mentioned cases can be handled with default data types - explicit nullable type is to add that additional state of nothing/null/nada to a value type.

Which is correct, because {} represents an empty object, which is not the same as no object (null).

Your json is wrong - an empty array is represented as [], not as null

Nullable<T> you mean?

I wonder when that will happen given the oldest mention of that version I remember was in 2010

you must be using a version before 10.3 - this has been fixed: https://quality.embarcadero.com/browse/RSP-11302

I am also glad we could find a solution - fyi the actual fix was done a bit different as suggested in the comments of that issue. Also thanks to @jbg who gave some input on the subject and @Bruneau who we worked with to get this solved.

Some of your functions have a defect as in returning an empty array when no delimiter is found - they must return a 1 element array with the input string if they should follow RTL behavior. Also you can remove some unnecessary branching and make the code simpler: function CustomSplitWithPrecountByIndex2(const aString: string; const aDelimiter: Char): TArray<string>; var i, resultLen, resultIdx, tokenPos, inputLen, lastDelimiterPos: Integer; begin inputLen := aString.Length; lastDelimiterPos := 0; resultLen := 1; for i := 1 to inputLen do if aString[i] = aDelimiter then begin Inc(resultLen); lastDelimiterPos := i; end; SetLength(Result, resultLen); resultIdx := 0; tokenPos := 1; for i := 1 to lastDelimiterPos do if aString[i] = aDelimiter then begin SetString(Result[resultIdx], PChar(@aString[tokenPos]), i - tokenPos); tokenPos := i + 1; Inc(resultIdx); end; SetString(Result[resultIdx], PChar(@aString[tokenPos]), inputLen - lastDelimiterPos); end;

Should be an (*1)array of (*2)pointer to libvlc_media_track_t passed by (*3)reference, no?

Spring4D has ISet<T> and 2.0 will introduce IMultiSet<T>

Isn't it usually Sheldon who comes up with ridiculous stuff just to win an argument?

@Lajos Juhász Already reported as RSP-24383 @A.M. Hoornweg Might be RSP-19835 that got you.

I think the reason why people keep coming back is that there is uncertainty about when it can be assumed that the data is aligned properly. A local or global variable for example is not guaranteed to be naturally aligned.

100% this - any other program built with a programming language that directly is built ontop of winapi works as well - you only need to change applications in order to use and embrace new features or recommendations (such as not storing configuration or user specific data next to the binaries in programfiles)

Just tested with some integers (where sorting stability does not matter anyway): - for random data non generic code is slightly faster simply because they can use the comparison operators instead of doing rather costly comparer calls (even if the comparer itself is the default one) - approx 2 times - already sorted almost identical speed - reversed sorted data timsort is like 8 times faster

If you actually clicked on the link I provided and followed the other links provided in that answer by Peter Cordes (who is like the Jon Skeet on asm related stuff on SO) you will ultimately find a quote from the Intel documentation (and the AMD one agreeing on that) which states: Which is why I wrote that it works when target is aligned naturally which means by 64 bit - that in itself ensures that it does not cross a cache line. Now arguing that the presented solution does not work when this is not given is kinda moot. Thomas stated that he wants to "set a double variable in a thread safe manner" - which I assume is meant literally and a double variable will be 64-bit aligned.

movq xmm0,[value] movq [target],xmm0 should do the trick when target is naturally aligned - for reference.

The lack of pdb support in Delphi makes it tedious to use because you only get addresses reported which you then have to manually look up.

Just pointing this out so you don't get yourself into trouble: IANAL but the fact that the IPP is under a commercial license or a free license if you qualify (time limited if I read it correctly - but I just quickly skimmed through it) might make it arguable to actually distribute any parts of it. If you know more about it I would be glad to be wrong. And as said before - even though your intentions are surely to make it easy for users - putting the source for those projects with an explanation how to build them would get you on the safe side.