FredS

I did, but I don't actually know what TWaitFor does.. I can tell you that the code you posted has a chance of being stuck not synchronizing.

For a quick test replace that with `CheckSynchronize(10)`. Optimal would be a MsgWaitForMultipleObjects waiting on Thread or Process Termination and the SyncEvent while handling messages.

What does that do?

@Anders Melander Yup, certainly no issues not already reported except maybe that the History list box is all black and can't be used.. since I haven't seen this reported I'm not sure if its W7 or RDP.. All in all RDP'ing is better out of the box in 10.4, 10.3 was useless without a fix from Andreas..

It's faster especially when you are only enumerating folders.. To do a real test one would have to access remote ADMIN$ shares, something like a 2012 server or newer with a huge directory tree.. Run a few of those on Azure and run them simultaneously (multi-threaded).. but not in 10.4 .. being able to retrieve the data in large chunks makes enough of a difference..

That would work if bugs found where actually fixed instead of disappearing into the internal pool of darkness..

After a couple of clicks on components the structure window no longer follows your selection. Right about then I realized that the structure window 'Find' control comes from DDevExtensions (@AndyHTech).. 🙂

I've seen it as a hint 'LSP has stopped working' or something similar. Only in one unit so far.. apparently new declarations in Winapi.Windows for some structures duplicated JwaWindows and that did it. ErrorInsight fails when you alter something and Codeinsight breaks after a couple of debug sessions.. But the most annoying is the keyboard.. maybe its because I'm trial running on an Unsupported OS (Windows 7) 🙂

This works fine, and I also use a home rolled method using FindFirstFileEx. As for multiple threads, I did that test a while back and it didn't show any better time.

That part sounds fair enough to me.. More troubling is that the New Embarcadero Licenses and Download Portal still has no method of handling license bumps as outlined by the post above yours. As it sits now I can be responsible and burn an ISO or make backups but I can't find a legal way to move my installation..

I'm also Primary contact and there has never been another, the email hasn't changed from Godzilla, yet nada.. Not that I was interested but some bot shouldn't know that 🙂

Once you have the type library imported see: ADsOpenObject

Agreed, used to be important.. but now that procedure navigation is done with tools like MMX that may no longer be required.

Having come back to code from last century I now comment things that may require additional time to read. Even just a one liner helps when you scan code. I also limit the use of 'With', had some of that a few levels deep before 🙂

Wasn't there also a clause that you can't even talk about it for 2 years after? Pretty sure its still legal to say; I won't be on it! 🙂

In Godzilla and beyond, at least for me.. Occasionally I run Rio when there are a lot of compiler directives in a file. Rio is a better Notepad++ than Berlin but eventually you need to run the code and it all ends by closing Rio and re-opening Berlin..

In Berlin the 64bit debugger outperforms the 32bit on my systems. Certainly crap from Godzilla on..

There are multiple issues, first and foremost is the response time for spawning threads. Then there are all those 'undocumented Features' new and old.. Remove the TMonitor in your Load and get rid of the Sum because the only reason to call that is to tax the system. Maybe switch to x64 and run that again, at least the time will increase in x64 and allow for more threads to be added. Don't forget to wait for them to idle out ~10 seconds then run two more times to see if it breaks with negative numbers, which should also give you increased times. See the negative idle in Rio 10.3.3:

CPU/Avg should be showing 100% else the lock is most likely throttling that or your implementation of formatted is off. I believe the point is to spawn MinLimitWorkerThreadCount ASAP and to make those available regardless of CPU load. Also the last [two] tests must be after the pool has cleared, usually 10 secs. Should have been included with the original code: //MMWIN:CLASSCOPY unit _MM_Copy_Buffer_; interface type TThreadPoolStatsHelper = record helper for TThreadPoolStats function Formatted: string; end; implementation function TThreadPoolStatsHelper.Formatted: string; begin Result := Format('Worker: %2d, Min: %2d, Max: %2d, Idle: %2d, Retired: %2d, Suspended: %2d, CPU(Avg): %3d, CPU: %3d', [self.WorkerThreadCount, self.MinLimitWorkerThreadCount, self.MaxLimitWorkerThreadCount, self.IdleWorkerThreadCount, self.RetiredWorkerThreadCount, self.ThreadSuspended, self.AverageCPUUsage, self.CurrentCPUUsage]); end; end.

Knew that was coming 🙂 This is a monumental task because some patches made it into Tokyo and I merged them while another I applied. I can't exactly publish System.Threading which alters some things dramatically. Will attach the RSP-11267 patch since it was applied over the unaltered Berlin Threading unit. Will add my notes so you get an idea of the changes and limitations. Will add the simple changes which alter the constants used. Not sure how I can deal with some of the core changes though.. Tokyo never made it onto my development machine, that merge was simply an easy way to create an intermediate file that should have been used to update Rio. But in Rio System.Threading was altered so that 1.5 years after its original release we still have to deal with posts like this one.. needless to say I never made that merge.. interface {$REGION 'History'} // earlier - Modified as per RSP-11267 // 09-Jan-2019 - Changed MonitorThreadDelay to 100 to be more responsive, if we are taking a clients system // to 95% CPU or higher shouldn't we be able to adjust that without a long pause // - Changed NumCPUUsageSamples to NumCPUUsageSamplesShort (1000ms) and NumCPUAvgSamples (5000ms) // - Changed Retirement Delay to 500ms Idle already can take 80-320 seconds // - Allow Parking/Suspending of unlimited threads, this is key when another application starts to // chew up resources while tasks have already been spawned // - Fixed CPU usage, was turned off after the last Queued task began work // - Fixed a silly timeout patch that should have used the NoWorker flag instead // Be Aware this may not be a perfect solution if more than one pool is created. // An Assertion has been added to highlight this possible issue // 10-Jan-2019 - Added RunningThreadCount // - Calling CreateMonitorThread always now; We want a Singleton MonitorThead regardless of the amount of Tasks requested // - Added Output2Debug function // 20-Jan-2019 - Merged non Tokyo specific changes from Tokyo // - There are Tokyo specific changes that must be done in a new File {$ENDREGION} {$I ..\..\MatchDelphi.inc} {$TYPEDADDRESS OFF} // required for Resource String Pointers {$SCOPEDENUMS ON} {-$DEFINE OUTPUT_DEBUG_STRING} // Activate to show Output2Debug Messages {$IFDEF DEBUG} {$MESSAGE HINT 'Altered System.Threading tested for Single/Default TThreadPool Only'} {$ENDIF} /// <summary-Fred> /// Changed MonitorThreadDelay to 100 to be more responsive, /// if we are taking a clients system to 95% CPU /// or higher shouldn't we be able to adjust that /// </summary> MonitorThreadDelay = 100 {500}; /// <summary-Fred> /// We keep two Averages now, one of 5 secs for standard output as before /// and another for 1 sec used to calculate Suspensions/Parking /// </summary> NumCPUUsageShortSamples = 1000 div MonitorThreadDelay; NumCPUAvgSamples = 5 * NumCPUUsageShortSamples; /// <summary-Fred> /// SuspendInterval is the value used to limit the number of threads that /// can be Parked, IMO this should reflect MonitorThreadDelay because that /// is the time it takes to recalculate the CPU Averages /// </summary> SuspendInterval = MonitorThreadDelay; // Interval to use for suspending work in worker threads /// <summary-Fred> /// Twice MonitorThreadDelay seems to work well /// </summary> SuspendTime = MonitorThreadDelay * 2; // Time to spend in SuspendWork; RetirementDelay = 5000; // Delay interval for retiring threads and finally the output of the original test: Altered Threading Berlin x64: Before: Worker: 0, Min: 4, Max: 100, Idle: 0, Retired: 0, Suspended: 0, CPU(Avg): 0, CPU: 0 After: Worker: 4, Min: 4, Max: 100, Idle: 3, Retired: 0, Suspended: 1, CPU(Avg): 100, CPU: 100 Finished in 00:00:37.3397033 Before: Worker: 4, Min: 4, Max: 100, Idle: 4, Retired: 0, Suspended: 0, CPU(Avg): 7, CPU: 3 After: Worker: 5, Min: 4, Max: 100, Idle: 4, Retired: 0, Suspended: 1, CPU(Avg): 100, CPU: 100 Finished in 00:00:36.4708368 Before: Worker: 5, Min: 4, Max: 100, Idle: 5, Retired: 0, Suspended: 0, CPU(Avg): 7, CPU: 0 After: Worker: 6, Min: 4, Max: 100, Idle: 5, Retired: 0, Suspended: 1, CPU(Avg): 100, CPU: 100 Finished in 00:00:36.2496669 Before: Worker: 6, Min: 4, Max: 100, Idle: 6, Retired: 0, Suspended: 0, CPU(Avg): 35, CPU: 0 After: Worker: 7, Min: 4, Max: 100, Idle: 6, Retired: 0, Suspended: 1, CPU(Avg): 100, CPU: 100 Finished in 00:00:36.2084714 Before: Worker: 7, Min: 4, Max: 100, Idle: 7, Retired: 0, Suspended: 0, CPU(Avg): 7, CPU: 0 After: Worker: 8, Min: 4, Max: 100, Idle: 7, Retired: 0, Suspended: 1, CPU(Avg): 100, CPU: 100 Finished in 00:00:36.8463683 Before: Worker: 0, Min: 4, Max: 100, Idle: 0, Retired: 0, Suspended: 0, CPU(Avg): 3, CPU: 0 After: Worker: 4, Min: 4, Max: 100, Idle: 3, Retired: 0, Suspended: 1, CPU(Avg): 100, CPU: 100 Finished in 00:00:37.0737835 1 - RSP-11267.patch

Then there is that undocumented 'Feature' where after you wait for termination your elapsed time goes from ~1s to ~81s: PPL Test --------------- Before: Worker: 0, (Min: 4..Max: 100), Idle: -9, Retired: 0, Suspended: 0, CPU(Avg): 5, CPU: 2 Finished in 00:00:01.6734632 After: Worker: 4, (Min: 4..Max: 100), Idle: -5, Retired: 0, Suspended: 0, CPU(Avg): 20, CPU: 100 ------------------------ After waiting for threads to terminate: PPL Test --------------- Before: Worker: 4, (Min: 4..Max: 100), Idle: -5, Retired: 0, Suspended: 0, CPU(Avg): 1, CPU: 1 Finished in 00:00:30.7872728 After: Worker: 4, (Min: 4..Max: 100), Idle: -3, Retired: 0, Suspended: 0, CPU(Avg): 20, CPU: 50 ------------------------ PPL Test --------------- Before: Worker: 4, (Min: 4..Max: 100), Idle: -3, Retired: 0, Suspended: 0, CPU(Avg): 1, CPU: 0 Finished in 00:01:21.6815195 After: Worker: 4, (Min: 4..Max: 100), Idle: -2, Retired: 1, Suspended: 0, CPU(Avg): 20, CPU: 100 ------------------------ I ran this in Berlin and it appears to work fine. But I made changes to System.Threading, both to achieve near 100% CPU usage as well as applying some of the patches submitted by those reporting to QC.. Then there is the issue that in Win64 this takes over 37 seconds, RSP-24570 is for CBuilder but its the same in Berlin and Rio 10.3.3

There are of course other things to consider. Bugs converted to Feature Requests, and then there is that Dark Pool of internal Bugs that get resolved by the hundreds..

OK but the 'don't complain' attitude is getting a little long in the tooth.. @Vandrovnik has a very valid argument, I've seen what he sees and there is NO VALID explanation for not updating things like the API for a decade or more.. Other than writing stuff about skins I guess 🙂

I haven't looked at Fastcode for ages, today I tried out the 'System.Generics.FastDefaults' unit only to find that the implementation of Murmur3 has changed. The latest one actually did NOT work at all for me... The one used in my tests is from the Initial commit: Alpha version 0.1 https://github.com/JBontes/FastCode/commit/7c47518e93870aaf155e70b6f43e3ba1dfb93898 Edit: Turned out that Berlin needed a restart, results of the same test (NewM3 being the one in the current master): Four Million (Murmor3,PreAlloc): 03.124-1398 Four Million (NewM3,PreAlloc): 03.078-7503

Yup, especially if true that xxHash64 on x64 outperforms..