Stefan Glienke

The general hints in the readme are very valuable (and made me revisit some of my ifdef checks) - apart from that it reminds me a bit of https://xkcd.com/927/ Yes, jedi.inc is long and unwieldy at times but it got everything commonly needed - in case it does not - wouldn't it be wiser to add that instead of rolling a new thing? Apart from that the prefix CAPS is kinda misleading imo - why not go with the HAS_ or SUPPORTS_ prefixes? Oh a note on your comment for bitness checking - the example does not entirely match what you describe, it specifically checks for x64 - so x86 and arm would go in the else. Bitness checks would be CPU32BITS and CPU64BITS or whats also common to check SizeOf(Pointer) = 4 for 32bit. Historically the checks are rather for x86 specifically to implement something using asm and then pure pascal in else.

From the looks yes because it makes sense - however you already cloned a repo with it when SourceTree did not even finish starting...

I did not read the article but a comment like this can only come from a person that has never worked in a team or on multiple features/versions. Or they actually did and had a total mess managing their stuff - I remember several video games in the past where bigger feature updates constantly introduced regressions that were already fixed in previous bugfix patches simply because they forgot to reapply those commits to their feature revision (no guess, this has been confirmed by the devs)

They are all available on all platforms and got introduced in XE3 - feel free to copy excerpts from Spring.pas - or some other libraries that have similar implementations For reference: https://bitbucket.org/sglienke/spring4d/src/ffee3360a2e8cb9ae5311621a745bb9ed809870f/Source/Base/Spring.pas#lines-2729 And let me know if you find any defect 😉

Currently very much enjoying this feature while running unit tests with a lot of exception checking under the debugger! 👍

Just a suggestion from someone who also wrestled with supporting multiple Delphi versions in his library: Use AtomicXXX throughout the code and declare them for the older Delphi versions that did not have them yet - that way you get the best code generated by the newer compilers that know about these intrinsics rather than putting indirections for everyone in order to be backwards compatible.

The current implementation of CMRs is full of lost opportunities: In C++ you can prevent copy/assignment simply by removing the copy/assign operator and it will not compile if you try - in Delphi we have to use runtime exceptions, yugh... In C++ you can directly access members on a unique_ptr or shared_ptr because you can override the * and -> operator - in Delphi you have to make some property to access the wrapped object. Oh, and thank you CMRs for making my code slower which does not even use them!

Picking up tests solely by [TestFixture] only works if you use {$STRONGLINKTYPES ON} or somehow reference the testcase class - otherwise the linker will strip it. That is why TDUnitX.RegisterTestFixture usually is a better choice (imo)

Reported and complained about numerous times - like https://quality.embarcadero.com/browse/RSP-21023 I think Allen Bauer somewhere explained this a bit more detailed but here is the short version I remember: The compiler internally takes some shortcuts and the part that produces the warning does not know that the var parameter it sees was originally meant to be the function result. My advice: spend a few bucks for FixInsight - it will catch this and other things the compiler does not.

Let's claim that our code is the critical 3% 😉

In the C++ community people usually tell you the compilers are incredibly smart (mostly referring to gcc, clang, msvc or icc) and you should not bother but just know some C++ tricks (constexpr wherever possible and alike). When talking about Delphi it would be an insult to most developers calling the compiler smarter when it comes to detecting patterns and optimization. However - unless you write core libraries like Arnaud or me you usually don't care.

No, it's not the same codegen, its a test and jnz less. You don't want forward jumps taken in the common case. Also a very important fact (I think it was mentioned before) - depending on where the compiler puts the code the hot loop code might cross cache lines - that slows things down significantly and can happen when you add or change unrelated code in other routines or in this routine - such as a check for Length or similar. When I let the routine start at some 64byte aligned address the loop body will cross cache lines and be slower. To my knowledge there is no way to control the alignment of generated executable code so that you can force hot code into a single or as few cache lines as possible.

If you really worry about performance in this area then don't use TCriticalSection but embed the TRTLCriticalSection (or the appropriate thing for POSIX) into the object where you need it - that way you also eliminated an indirection. And make sure that your allocated memory from the memory manager is aligned cacheline friendly (it won't by default)

RAD Studio Project - every Jira project has a unique code

@Rollo62 Reminds me of Zen of Python

Slightly OT: Use whatever you want for private projects or within a company but please - whenever someone does open source don't turn off possible contributors by having to install yet another VCS. Git has won, deal with it!

Now that is clearly shorter than calling dcc32! /irony off

I challenge you to write this method in a more performant way than what it currently is without completely turning it into an even less readable mess: https://bitbucket.org/sglienke/spring4d/src/534d63bccd0891d165d6cee1cbfff18df790661e/Source/Base/Spring.pas#lines-10122

@vfbb Depending on the tree the balancing is pretty damn efficient - but the memory layout after a few iterations can be totally screwed up which I mentioned earlier. But as always it depends - there is no "best for everything" data structure or algorithms but you typically want the "reasonably well for most cases" (bonus if they are "not exceptionally terrible for some rare cases"). Typically the decision is if the thing is often read or often written. If both is the case you have to evaluate the costs of going down the rabbit hole of implementing some special case data structure or simply roll with some standard implementation.

What Kas said - it's similar to the performance of array vs. linked list on modern computers - using objects or any dynamically allocated memory without special suballocator that ensures clustered memory and cache friendly layout will cause memory that's scattered all over the heap the longer the data structure exists unless you perform some defragmentation. Also using objects wastes at least precious Pointersize*2 Bytes of memory for every node. If you then throw virtual methods into the mix you very likely end up with a pretty terribly performing tree structure compared to how it could perform according to its big O.

A binary search tree that uses objects as nodes will be crap if you are after the pure performance advantages of a BST simply because all the cache misses caused by indirection will blow it out of the window. Simply talking about the Big O of the algorithm does not tell the full story because it simply ignores all those factors.

Because msbuild opens an entirely different can of worms and actually requires a dproj - compiling some dpr with dcc is a no brainer

Open cmd, type dcc32 it prints (almost) all parameters. You will find the -NS switch for namespace search path. So what you do is pass -NSvcl (probably there are some more needed such as Winapi - just take those that a new project in Delphi usually gets)

By the way: LoopStuff.dpr.26: while i < count do 0041BDB0 3BFB cmp edi,ebx 0041BDB2 7E0C jle $0041bdc0 LoopStuff.dpr.28: dosomething(i); 0041BDB4 8BC3 mov eax,ebx 0041BDB6 E8D5FFFFFF call dosomething LoopStuff.dpr.29: inc(i); 0041BDBB 43 inc ebx LoopStuff.dpr.26: while i < count do 0041BDBC 3BFB cmp edi,ebx 0041BDBE 7FF4 jnle $0041bdb4 LoopStuff.dpr.26: if (i < count) then // this branch can be emited if i holds at compile time. 0041BDB0 3BFB cmp edi,ebx 0041BDB2 7E0C jle $0041bdc0 LoopStuff.dpr.29: dosomething(i); 0041BDB4 8BC3 mov eax,ebx 0041BDB6 E8D5FFFFFF call dosomething LoopStuff.dpr.30: inc(i); 0041BDBB 43 inc ebx LoopStuff.dpr.31: until (i = count); 0041BDBC 3BFB cmp edi,ebx 0041BDBE 75F4 jnz $0041bdb4 As I said: sometimes the compiler does the check at the top for the while loop.

@Mahdi Safsafi I would not use that code as evidence because there actually the for loop produces better code than the other one. I was talking about while x do loop vs if x then repeat until not x conversion. Also it makes a difference if you have a static count or not - the benefit of the for to loop is that the compiler does no additional cmp after it decrements the internal "counting down to zero" variable but does the conditional jmp depending on the outcome of the dec. An until loop produces an additional cmp instruction (reported as https://quality.embarcadero.com/browse/RSP-22124) As always: it depends - while I certainly would not use a for-to loop when dealing with some string parsing but rather prever PChar I just found recently that using a for-to loop with indexing into a pointer was faster than inc(thatpointer).