pyscripter

The optimal thread pool configuration for IO intensive task is of course different that that for computational intensive tasks. The first case calls for many more threads than the second, since the tasks are in waiting state most of the time. System.Threading allows to have separate thread pools for different sets of tasks.

@farcodev32 logical processors, Wow! What is your CPU? How many cores does it have? It appears to be super fast.

 @Primož GabrijelčičAt least in Rio it seems to work OK: program Project2; {$APPTYPE CONSOLE} uses WinApi.Windows, System.Diagnostics, System.Threading; procedure TestParallel; Var TaskArray: array [1..100] of ITask; begin for var I := Low(TaskArray) to High(TaskArray) do TaskArray[I] := TTask.Create(procedure begin Sleep(100); end).Start; TTask.WaitForAll(TaskArray); end; begin var SW := TStopWatch.StartNew; //TThreadPool.Default.SetMinWorkerThreads(50); TestParallel; WriteLn(SW.ElapsedMilliseconds); WriteLn; Var TPS := TThreadPoolStats.Default; WriteLn('WorkerThreadCount: ', TPS.WorkerThreadCount); WriteLn('MinLimitWorkerThreadCount: ', TPS.MinLimitWorkerThreadCount); WriteLn('MaxLimitWorkerThreadCount: ', TPS.MaxLimitWorkerThreadCount); ReadLn; end. Output on an 8 processor machine: 1370 WorkerThreadCount: 9 MinLimitWorkerThreadCount: 8 MaxLimitWorkerThreadCount: 200 Output with TThreadPool.Default.SetMinWorkerThreads(50); 233 WorkerThreadCount: 50 MinLimitWorkerThreadCount: 50 MaxLimitWorkerThreadCount: 200 With TParallel.&For it works differently and the number of threads created relate to the number of processors.

@Rudy VelthuisGood stuff. How can we have a look at your new code?

Of course not. However parallel programming is not a piece of cake. There are so many ways you can shoot yourself in the foot and then blame the library.

Please allow me to disagree. I have made non-trivial use of System.Threading in PyScripter (used by thousands of users) without any problems. The main issue I know of with the library is RSP-11267. You can see a fix in that report, but even without the fix you can work around the issue by using a different mechanism for signalling task to stop As for Parallel.For I have not used it extensively, but you can see some code of mine in this StackOverflow question that I think is now used in a commercial product. An issue with thread creation by Parallel.For (RSP-21177) has been fixed in Rio. Advantages of System.Threading: By far the easiest way to use tasks (as opposed to threads) in your delphi application Nice interface using anonymous methods Avoids third-party dependencies It provides usage statistics that can be used for diagnostic purposes Nowadays, it provides good performance out of the box, but you can still fine-tune the way it works if you are prepared to dig-in It uses state-of-the-art synchronization techniques @Primož Gabrijelčič can correct me on this, but by reading his book "Delphi High Performance", I think, that depending on the type of use, is competitive if not faster than his own OmniThreadLibrary The Parallel library, like many other new features of Delphi (e.g. Generics) got a bad reputation, due to the many bugs in the early days. Unfortunately. trust is easy to lose and very hard to rebuild. But the library does deserves some love from Embarcadero (fixing remaining issues) and Delphi users.

Thanks very much. By the way the Unit Clause Manager with the Identifier tab is super! Much better than the built-in Find Unit (crashes most of the time) and more reliable than the also good RFindUnit.

CreateWindowHandle/CreateWnd are VCL Wincontrol routines that can be overwritten to take action that needs to happen when the WindowHandle of a control gets (re)created. There are corresponding routines DestroyWindowHandle/DestroyWnd, but these routines are only called when the control is recreated and not when it is destroyed. It appears that this is known, see for example here and here. I came across this issue because I wanted to do the following when a contol's handle was created: RegisterDragDrop (Handle, DropTarget); and this has to be matched by: RevokeDragDrop(Handle); at handle destruction. Initially I placed the first statement in an overwritten CreateWindowHandle and the second in DestroyWindowHandle. This resulted in memory leaks and I began to investigate. Here are the results of the investigation that I wanted to share with you in case you face the same issue. 1. DestroyWnd is only called when recreating the control (not at control destruction). It also calls DestroyWindowHandle. This is documented in the help file. 2, DestroyWindowHandle is called by DestroyWnd and separately by TWinControl.Destroy if WindowHandle <>0. So it looks like my solution should work, however, when the control is a child of a TCustomForm and the form gets destroyed (almost always the case), TCustomForm.Destroy calls DestroyWindowHandle before destroying child objects and Windows, before destroying a control's handle, it first destroys the window handles of all child objects. So the DestroyWindowHandle of the child controls will not be called! WindowHandle = 0 inside TWinControl.Destroy. The choices you have for taking action before handle destruction are: 3. WM_DESTROY handler. It is called by windows before destroying the window handle of child controls. 4 WM_NCDESTROY handler. It is called by windows after destroying the window handle of child controls and before destroying the control's window handle. I ended up putting RevokeDragDrop inside the WM_DESTROY handler, since this is called in all cases the window handle gets destroyed. Although not a bug, this looks like bad VCL design to me and can be the source of many bugs.

There are pretty good instructions at https://github.com/project-jedi/jcl and https://github.com/project-jedi/jcl Basically you either clone the repositories or download and unzip the zip files. Then you run install.bat. Installed without much trouble.

@Stéphane WierzbickiJust a thought. Since many of us use Rio without facing this issue it appears likely that one of these 3rd party components and experts does not play well with Delphi Rio. An idea would be to start removing these 3rd party components and experts until the IDE becomes stable/responsive. Or work in the opposite direction. Start without any third-party items, confirm IDE works well and then add them one by one.

@Dalija Prasnikar I think @Primož Gabrijelčičmakes the point that the object is destroyed after 'Test Complete' e.g. procedure Test; begin Writeln('Test started'); begin var obj := Shared.Make(TTestObj.Create)(); Writeln('obj = ', obj.ClassName); end; Writeln('End of nested scope'); Writeln('Test completed'); end; Output: Test started TTestObj.Create obj = TTestObj End of nested scope Test completed TTestObj.Destroy I think this is because the result of Shared.Make(TTestObj.Create) which is a reference to function is not explicitly assigned to any variable so its scope is the function scope. The statement begin var obj := Shared.Make(TTestObj.Create)(); implicitly assigns the result of the function call to the obj whose type is TTestObj.

@Primož Gabrijelčič If you do a minor change in Test (remove ()) procedure Test; begin Writeln('Test started'); begin var obj := Shared.Make(TTestObj.Create); Writeln('obj = ', obj.ClassName); Writeln('End of nested scope'); end; Writeln('Test completed'); end; Output: Test started TTestObj.Create obj = TTestObj End of nested scope TTestObj.Destroy Test completed

One final remark. If performance is an issue with a "with" statement performance improves to classic levels i.e. procedure MeasureSpring; var i: Integer; begin var s := Shared.Make(TStringList.Create); with s() do for i := 1 to ADD_COUNT do Add(i.ToString); end;

And for the record:

As pointed out In another post by @Primož Gabrijelčič, in Delphi Rio you can just write: var s := Shared.Make(TStringList.Create); What an amazing hack Shared is! Also impressive type inference from Delphi.

@John KouraklisToo many to mention.

I don't have such an issue here with default settings and complex Vcl projects loaded.

This is a very promising change in Windows. However right now it breaks many things including Excel addins.

Could anyone help with this Stackoverflow question?

Never mind. I found the answer. If you want to find out how to monkey patch a strict private class method (function) in a way that works in both Win32 and Win64 have a look at the above link.

I used to think that activating the compiler option "Use debug dcus" had minimal impact on performance. I hadn't done any benchmarking but from experience I could not tell the difference in performance. So I would include debug dcus even on release versions, so that full stack trace information would be available. But in my recent tests regarding the performance of Regular Expressions, I found that activating this option would increase run times by as much as 70-80%. Does anyone has done any benchmarking or have any rough idea about this? Is the large performance hit specific to this case? Can you still get full stack trace information without using debug dcus? (I am using jcl's Debug expert for exception reporting, with jdbg info linked into the executable). Example stack trace:

@dummzeuch I checked again and without debug dcu's you do not get line information for vcl and rtl routines in the call stack, when using jcl debug. This was the reason I was using the "debug dcus" option.

Ctri+H works fine for me. If then I select Editor Experts or press E I get what is shown by @David Hoyle above.

If you are using Regular Expressions in Delphi you may want to vote for this https://quality.embarcadero.com/browse/RSP-21733. JIT can make a huge difference in PCRE performance.

When I use the GExperts. Editor Experts menu command there is no submenu. A popup menu appears in the editor blank (with no visible entries).