Stefan Glienke

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

No, unless you reference the helper type itself somewhere which you typically don't and if you do you can just register the function somewhere so you don't need to use RTTI.

No, consts are consts and no types (even if nested in types) hence no RTTI Whatever you are trying you are probably better using something like DelphiAST and include that into your build process to generate something from source.

@Emil Mustea You could be that clever however the real runtime overhead of the spring smart pointer is so small that any such tricks are not necessary imo and rather lead to defects because of implicit variables as shown earlier. @pyscripter YMMV but when I compile with release config the results are within 2% difference. Depending on order and CPU caching in that micro-benchmark they are even equal.

That would have caused a ton of unnecessary extra initializations because of out param. If the compiler would actually be clever and detect them and omit when unnecessary I would agree. Also if it would not be that terrible it could actually give the warning regardless the internal working of the parameter.

The ISafeGuard approach is not a smartpointer but creating a scope to some resource. There is a important difference: a smart pointer combines the resource and its lifetime management into one entity. Also the record based approach is the most naive one - while Spring4D offers this one as well it has a more advanced one. As for performance: measure it yourself: program MeasureIt; {$APPTYPE CONSOLE} uses Spring, Diagnostics, Classes, SysUtils, JclSysUtils; const ADD_COUNT = 10; CREATE_COUNT = 100000; procedure MeasureSpring; var s: IShared<TStringList>; i: Integer; begin s := Shared.Make(TStringList.Create); for i := 1 to ADD_COUNT do s.Add(i.ToString); end; procedure MeasureJcl; var s: TStringList; g: ISafeGuard; i: Integer; begin s := TStringList.Create; Guard(s, g); for i := 1 to ADD_COUNT do s.Add(i.ToString); end; procedure MeasureClassic; var s: TStringList; i: Integer; begin s := TStringList.Create; try for i := 1 to ADD_COUNT do s.Add(i.ToString); finally s.Free; end; end; procedure Main; var sw: TStopwatch; i: Integer; begin sw := TStopwatch.StartNew; for i := 1 to CREATE_COUNT do MeasureSpring; Writeln(sw.ElapsedMilliseconds); sw := TStopwatch.StartNew; for i := 1 to CREATE_COUNT do MeasureJcl; Writeln(sw.ElapsedMilliseconds); sw := TStopwatch.StartNew; for i := 1 to CREATE_COUNT do MeasureClassic; Writeln(sw.ElapsedMilliseconds); end; begin Main; Readln; end. The implementation in Spring 1.2.2 (currently released version) uses very optimized code for the smart pointer itself avoiding the overhead of an object allocation and all the code associated with it but only allocates a 12 Byte (32bit) block with the IMT. Since IShared<T> is not a regular interface but an anonymous method you can directly access the members of the underlying type. Yes, there is a method call every time but as you can measure that does not cause any significant overhead (unless you call .Add a million times). And even then the actual work being performed totally outweighs the smart pointer overhead

*facepalm*

The patches that went in 10.3 are mostly IDE related and not compiler related afaik. Also from a few comments about the progress dialog alone affecting the duration of the compilation I have the strange feeling that inside the IDE the progress callback is wired a bit wrong (synchronous instead of asynchronous) causing unnecessary extra slowdown.

You, the container only is responsible for singleton lifetime