Stefan Glienke

The claim that it compiles faster is bogus - prove me wrong. Most compile time from spring4d comes from generics, which I reported years ago. Also, my suggestion for third-party libraries is to pre-compile them, which removes any dependency on the project options in your project. Currently, Spring4d supports down to XE, and as long as that is the case, I am not putting even more conditionals into the code than there already are.

Why?

Just a few new numbers of a not yet released parallel pdq sort - using the benchmark code from this comment earlier in this thread Fill array (double), elements count: 500000 Start sorting ... RTL TArray.Sort (ms.): 47 RTL TParallelArray.Sort (ms.): 35 Spring TArray.Sort (ms.): 12 Spring TArray.Sort_Parallel (ms.): 3 Fill array (double), elements count: 5000000 Start sorting ... RTL TArray.Sort (ms.): 551 RTL TParallelArray.Sort (ms.): 128 Spring TArray.Sort (ms.): 136 Spring TArray.Sort_Parallel (ms.): 64 Fill array (double), elements count: 100000000 Start sorting ... RTL TArray.Sort (ms.): 12724 RTL TParallelArray.Sort (ms.): 1884 Spring TArray.Sort (ms.): 3035 Spring TArray.Sort_Parallel (ms.): 675 Again - these numbers are fluctuating a bit because the benchmark is a "run once" benchmark and it depends on the current CPU state etc - also I did not tweak the threshold and CPU count yet - simply calling TTask.Run from System.Threading to fork some slices into parallel execution. But overall it does not look too bad, doesn't it?

Of course, he says that - he wants to sell his overpriced garbage

Because as you can read in this thread people advocate for using it everywhere instead of at those rare places it's designed for: making sure the reference is set to nil before the instance is destroyed because any code being called during destruction might reach back to this very reference. (which is the reason its name is not even correct - it should have been named NilAndFree)

Using FreeAndNil is the very essence of https://en.wikipedia.org/wiki/Cargo_cult_programming

It appears that Marco lacks the technical understanding to evaluate this issue. I left a comment.

The issue with your code is that it captures Self - if you avoid that, your problems go away.

Reducing instead of eliminating the probability of AVs (or other errors caused by races) in async code is one of the most annoying things you can do - anyone who ever was on the hunt for that "one in a billion times" bug knows that. I cannot believe that people who should know better give such advice.

The best practice is coding in a way that you don't need it

It always is just a matter of taste - I don't particularly like the parameter and local variable prefixing so I mostly settled on the C# naming conventions for those - I did not want to go that far to name fields with a leading underscore like them though. Though this is not without disadvantages - I had cases where I had a count parameter and wanted to access the Count field but without qualifying with Self I accessed the parameter instead. (those are the days where I wished for case sensitivity) Because being open source means that everyone can go ahead and modify it to their liking, right?

Looks great - as always: spring4d source for the real test and it seems to stumble at a few places where it then goes into "line breaks go to 11" mode - here for example: or

That comment didn't age well I guess

I bet the C++ code does not do the same as TIniFile in Delphi which calls WritePrivateProfileString for every entry.

Without saying too much there is the possibility that this issue (https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-2458) will be fixed in the next release.