Leaderboard

Yes. For one you are running all the tests concurrently which means that you will be penalizing the tests that start later because they will be competing for CPU against the test that are already executing. Execute each test and wait for it to finish before you start the next test. You also seem to have massive memory leaks which probably means that some of the test have an unfair advantage because they don't consume time releasing their resources. If you are using thread pools (I'm not sure that your are (if not, you should be)) then you should ensure that the thread pool has been spun up before you start the test. Otherwise you will penalize the first threads with the startup overhead. Instead of just looking at the time from start to end and then guessing about why it is fast/slow/whatever, profile your code so you can see exactly where the bottlenecks are. Do this for each individual algorithm in turn. Apart from that, for something as simple as this, you don't need locking and you definitely don't need to use the Windows message queue as a work queue. Use a simple lock-free fifo queue instead. You could even use a fixed size lock-free ring buffer (just an array of records with two integer values as in/out indices). The fixed size buffer and the records would eliminate the allocation overhead of the queue itself. You should probably also try to eliminate the use of string and replace it with fixed size buffer if possible.

I've created a demo in my HowTo repository. It also demos a way of accessing the contents of the files, since you cannot use the "traditional" methods of accessing the files in Delphi.

I solved this issue as follows: first, I ran the command rm ~/Library/MobileDevice/Provisioning\ Profiles/*.mobileprovision in the Mac terminal, in Xcode, I went to Settings > Accounts > Download Manual Profiles. Finally, I restarted the PA Server, and everything worked correctly

I didn't investigate but I got a lot of leaks reported when existing the application when running in the debugger. Okay. It's expensive to start a thread but if you are launching the threads at application startup then it doesn't matter. If you create them on-demand then I would use TTask instead. The first task will take the worst of the pool initialization hit. https://en.delphipraxis.net/search/?q=profiling If you use a lock-free structure then you don't need locking. Hence the "free" in the name 🙂 And FTR, the term deadlock means a cycle where two threads each have some resource locked and each is waiting for the other to release their resource. I think what you meant was race condition; Two threads modifying the same resource at the same time. PWideChar is supposedly a pointer to a WideString? In that case, please don't. WideString is only for use in COM and it's horribly slow. No, what I meant was that instead of using dynamic strings (which are relatively slow because they must be allocated, sized, resized, freed, etc.) use a static array of chars: Buffer: array[BufferSize] of char. You will waste some bytes but it's fast.

Why you don't use TMonitor ?

Thanks to @jaenicke It's necessary now to ask once for Context.getExternalMediaDirs open the path once and then the directory is created on SD card again. This was not necessary before. uses Androidapi.JNIBridge, Androidapi.JNI.JavaTypes, Androidapi.JNI.GraphicsContentViewText, Androidapi.Helpers; function GetExternalMediaPath: string; var Context: JContext; mediaDirs: TJavaObjectArray<JFile>; mediaDir: JFile; begin Result := ''; Context := TJContext.Wrap(SharedActivity); if Context <> nil then begin mediaDirs := Context.getExternalMediaDirs; if (mediaDirs <> nil) and (mediaDirs.Length > 0) then begin mediaDir := mediaDirs.Items[0]; if mediaDir <> nil then Result := JStringToString(mediaDir.getAbsolutePath); end; end; end;

Looks like I was wrong about that. Compiling the FCMBaseDemo in Kastri, using the Firebase iOS SDK v11.11 succeeds using Delphi 12.3. Might have been another SDK I was thinking of 🙂

D12.3, latest Git release of Rapid Generics 2, 64-bit testing using RapidGenericsTestSuite: [dcc64 Error] uListTest.pas(2225): E2532 Couldn't infer generic type argument from different argument types for method 'AreEqual'

True thing. Please update the source code from github repo. It's fixed now and there are a few new test cases to cover TObjectList (tests for TObjectList are not complete yet). Thanks

Because the language spec - pardon, the compiler - says so. Constraints on generics are part of the declaration.

"It's not the bottleneck, therefore, I don't care" is the reason why Embarcadero does not care to implement anything that is reasonably optimized.