Stefan Glienke

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?

The term for that is Cargo cult programming

Not really as you can turn off this warning with {$WARN NO_RETVAL OFF}

You can put attributes almost everywhere without any errors, that does not mean that they are planned to be supported in these places.

I add Generics.Collections to some uses, then ctrl+click on it, boom Anyhow this is not the issue here as Uwe said, even 500 million failed createfiles are not burning a CPU core but rather the HDD/SSD. How you can see what is burning your CPU was explained in the other thread.

Create a new vcl application. Add any third party unit (one that is not immediately found in the first entry in the library path) - thus not a Delphi RTL/VCL/... unit or a Delphi unit without its fully qualified name. Then compile. The more entries you have in the library path and the more entries in the project options in unit scope names the more entries will pop up in procmon because it tries every possible combination (I don't remember in which order)

Probably - as far as I can see on saturday Stéphane wrote about the fresh install and referred to the wrong registry key being accessed. Yesterday he wrote about a fresh VM installation - at that point he did not claim that Rio was not installed without third party components. And if you look into the file he talked about earlier in this thread you can see that it uses quite a lot of third party stuff (like TMS Aurelius).

@Stéphane Wierzbicki @Attila Kovacs You should learn what procmon is telling there - all these attempted createfile are results of checking if the file exists and all the directories are obviously directories in the library path as a result of installing several third party components. And due to the way Delphi handles library/search paths when compiling (iterating them looking for the requested file and trying them with any possible unit scope - that is why you see it trying Vcl.Shell.blabla there, because usually Vcl.Shell is one of the unit scopes being put into a VCL project) this is what you get - nothing unusual there.

Yes, you can improve the compiler (the language) as much as that it is partially safe to access raw memory without copying it - google for: .NET Span<T> I did some experiments with it in Delphi and it improved some string parsing code that did not have to allocate new strings but also did not have to work with raw and rather unsafe PChar. See https://bitbucket.org/snippets/sglienke/7e6xoe/span - this however cannot do what the C# compiler can do with ref (ensure that it only lives on the stack to not lives longer than what it refers to and these things) plus C# has readonly ref - basically a readonly pointer.

Probably not for Delphi because there is virtually no market but you would be surprised what static code analysis can do.

Simple, one that knows that you are pointing to an array element and sees that you are resizing the array thus invalidating this pointer.

No