Stefan Glienke

The approach to store Min and Max Value for sets does not work as sets in Delphi can be max size of 32 Byte (set of Byte) - good luck storing that in an Integer. The core idea though is nice - I think I have also done this before: use a generic type as storage for type related values.

Technically in Delphi strings are only mutable if they have a ref-count of 1, otherwise a copy happens. And while it might be convenient to the average developer if you actually look under the hood how much instructions and implicit heap allocations happen if you are not paying attention and naively work with strings you will be scared.

- the december patch does not mention anything about IDE stability fixes - IDE FixPack is not yet released and only alpha state (and even may cause issues - well more precisely the CompilerFixPack for 64bit windows does - see https://quality.embarcadero.com/browse/RSP-23405) - DDevExtensions does not fix IDE stability issues but adds productivity features I am only using 10.3 for toying and it more often crashes (well the compiler gets into some state where it produces nothing than some internal errors after it eventually brings down the IDE) - and yes I am using the IDEFixPack alpha because I am not producing any production software with it.

https://stackoverflow.com/questions/22397861/why-is-string-immutable-in-java https://stackoverflow.com/questions/2365272/why-net-string-is-immutable

As I mentioned before the jump optimization highly depends on the CPU - and of course it only affects methods that are being called and not inlined. When inlined you have a jump no matter what. Only when being called it can benefit from two returns in each branch to avoid the jump over. Edit: Clarification - when inlined, putting the raise first is better because it only needs one conditional jump instruction (jump over raise call or not), taken in the common case. When putting it below it still has the conditional jump which is not taken in the common case but has a jump over this code in all cases when the common path is being used. What I would do regardless is to put the exception raising code into a non inlined subroutine to reduce generated binary code because then the code being jumped over is just a call (5bytes on 32bit). Another optimization is to make use of {$POINTERMATH ON} for your pointer type because then you can write: Target := @FData; Target[FCount] := AItem; And another neat trick to check if an Integer index is in range that only uses one compare: if Cardinal(AIndex) >= Cardinal(FCount) then By the way - putting all cases into the same binary often influences results and even the order in which you execute them changes the output - I had a similar case where just changing order made one or another faster or slower. Measuring performance is not as easy at it sounds :)

Any pure speed benchmark would be rather useless/biased because it all depends on what you are in fact doing apart from creating the list. If this workload is small enough the object creation would mean a significant overhead. In the end you would just benchmark object creation. Also what affects performance is pointer indirection and memory, CPU cache. In some micro benchmark this would not occur as all memory fits into L2 or even L1 cache. Benchmarking the effect on heap usage/fragmentation is way harder because that cannot be done in pure isolation and usually only manifests in production. FWIW performance for System.Generics.Collections.TList<T>.Add (and other methods) between 10.2 and 10.3 also differs quite significantly (got better). And another thing that sometimes significantly improves performance when adding items to a list is to preset its Capacity to avoid reallocations - in the example given in the blog article with adding 64 integers this already improves performance by 33%.

Turn ZBS off for that code and use 1.

Yes, and performance of these things sometimes heavily differs between the different CPUs (for example I had a case where I got some severe slowdown in some code on my ivy bridge i5 whereas it was not there on a skylake i7 one). Anyhow not having a jump is still better than a predicted one. But that is micro optimization (which I did invest some time into as the code I was testing is core framework code, which I usually consider collection types part of).

No. I don't know about the ARM codegen but on windows if you do the pattern: if out of range then raise exception; do stuff; This always generates a jump above the raise to get to do stuff for the common case of "in range". When you write: if in range then do stuff else raise exception; In this case you don't have a jump for the common case of being in range. Depending on how you structure the code you then have two returns in each branch of the if so no jump inside the method. If you like to inline this method it is also a good thing to put the raise exception into its own subroutine to not bloat the inlined code.

And if you then write the Add and GetItem methods better so they don't do unnecessary jumps every time and can be inlined it will be even faster.

What's also interesting about Length and High is that if you are just writing code that directly compiles into a binary they are being inlined by the compiler whereas if you are using them in units that are pre-compiled as part of a package (if you are 3rd party component vendor for example) they are not and always cause a call to System._DynArrayHigh and System._DynArrayLength. Funny enough this is not the case for the source shipped with Delphi because their DCUs are not generated from their containing packages.

This bug has already been reported before but since QP is not responding right now I cannot look for it.

I don't see the Delphi compiler performing any control flow analysis and eliminate code in any possible future. C++ might do that though (see https://stackoverflow.com/questions/6664471/observable-behaviour-and-compiler-freedom-to-eliminate-transform-pieces-c-co) However I requested adding a way to specifically force linking of types into the binary some while ago - see https://quality.embarcadero.com/browse/RSP-18389

And that's why technical terms matter - because it's called parking brake (Feststellbremse in german).

Well not trunk but in fact Mercedes Benz I think was the first manufacturer to put it somewhere else and often people were looking for it in the usual place and could not find it :)

Looks like a similar story as with some other acquisitions - bought when decreasing relevance kicked in (in this case I think CircleCI their direct competitor gained quite some marketshare from Travis for several reasons).

Thanks for pointing that out - in the currently released version the type still has a T in its name and is in the unit Spring.Designpatterns (the move and renaming happens in the upcoming 1.3 version which is not yet released). Also in both versions the explicit hardcasting of the anonymous method is not required - there is an implicit operator for that. Also FWIW I usually put specifications that are used in several places as static functions into their own type or helper just like this (you can also make them standalone routines if you dislike the redundant typing of TProjectFilters): type TProjectFilters = record class function IsActive: TSpecification<TProject>; static; class function WorkhoursGreaterThan(const value: Integer): TSpecification<TProject>; static; end; class function TProjectFilters.IsActive: TSpecification<TProject>; begin Result := function(const p: TProject): Boolean begin Result := p.Active; end; end; class function TProjectFilters.WorkhoursGreaterThan( const value: Integer): TSpecification<TProject>; begin Result := function(const p: TProject): Boolean begin Result := p.Workhours > value; end; end; var spec: TSpecification<TProject>; begin spec := TProjectFilters.IsActive and TProjectFilters.WorkhoursGreaterThan(50); Also what others already pointed out: lets look at for example CountActiveProjects and ListActiveProjects - what do they have in common? They do something on the active projects - so break that down into getting the active projects and what is done on them. If you want to keep TArray<TProject> and alike you probably have to write the filtering yourself. I just point out how easy it will be using IList<T> from Spring.Collections: procedure PrintProject(const p: TProject); begin //... end; var projects: IList<TProject>; activeProjects: IEnumerable<TProject>; begin activeProjects := projects.Where( function(const p: TProject): Boolean begin Result := p.Active; end); Writeln(activeProjects.Count); activeProjects.ForEach(PrintProject); You can even turn a TArray into an IEnumerable where you can apply filtering and stuff (yes, some minor overhead - measure yourself if it's worth it to keep your code compact and with less explicit loops); var projects: TArray<TProject>; activeProjects: IEnumerable<TProject>; begin activeProjects := TEnumerable.From(projects).Where( function(const p: TProject): Boolean begin Result := p.Active; end); Writeln(activeProjects.Count); activeProjects.ForEach(PrintProject);

Well, not quite - it's not a common case but I want to point that out: If you have any existing 64bit DLL that you compiled with a previous version and are now calling from a 10.3 compiled binary or vice versa that has any of the affected record types you are in trouble. You need to compile both with the same version. Also if I am not mistaken it is between 5 and 8 bytes, 4 bytes fit into a register on both and should not be affected.

Has nothing to do with that - I suspect that the dproj was migrated from a version before 10.3 where someone tested with those options. Since there is no IDEFixPack for 10.3 yet, these options will have no effect.

https://andy.jgknet.de/blog/2018/06/ide-fix-pack-6-3-released/

My point was that countering that there is "uncontrollable behavior" sometimes with showing that there is nothing wrong when firing off a bunch of sleep threads is useless. A thread that does nothing but sleep suspends and gives control back to the OS scheduler which knows not to wake up that thread until time is over. You can see that in the numbers you posted. Also when doing IO heavy stuff you hardly want to put that into CPU threads but use I/O completion ports.

Second alternative possibly does an unnecessary instruction but the first has a jump in both cases - so it depends. If you are micro-optimizing code (which you usually don't) you might want to keep the common path jump free.

Because Sleep "suspends the execution of the current thread" (see MSDN) opposed to some "real" work. That might or might not affect significantly the behavior of the threading library itself depending on where it has glitches or not.

No offense but I cannot take people serious that test any threading library code by putting sleep into their thread execution to simulate any real workload...

@Lars Fosdal Goto where?