DelphiUdIT

Like @Anders Melander said, the Task Manager is not the right instrument to measure the performance of your application. One of the simple way is to measure the time the your software needs to do some tasks. Compare with old systems (if you can) or analyze with the datas that you histrical have. If you really use a bunch of threads you are not able to "consume" all processor power. You can measure performance datas with "profilers" or simply usingn "time base view" with TStopWatch (from System.Diagnostics) for primitive analyses.

First of all, the CPU % in task manager is about all threads (I mean cores with hypert. and not). If you use only some cores (and the decision is made by the ITD) the CPU usage never go to 100%. I can assure you that you can reach the full power of you processor. In my applications I stay form 50% to 90% of CPU usage using all possible Corse, but I use in my apps more then 30 TThreads.

In the past I used to compile app with ARM (I think V7 32 bit, but not sure) with Delphi and run in a Tablet with Intel processor ATOM 64 bit (like Asus ZENPAD 8"). I really don't know the procedure. I remember that I have to delete some so files ... Sure he can help: @Dave Nottage

OOps ... sorry I didn't note that ... except "Queue" than he can use "Synchronize" (is not async), the others things should working.

May be you can have found the right way ... (BDSINCLUDE)\windows\vcl is already included in the standard global path of C++. But I have to modified the "All Configuration" settings in the options .... THAT WORKS ... GREAT. EDIT: If you cannot enter in the QC portal I will report that with your refer (this topic) ....

I always used TThread, the object include in the standard lib with Delphi. With that you can do everything. Use "Queue" method to interact with VCL components. Ref: https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Classes.TThread If you have time, explore the use of WaitForxxx with events in Threads ... they can help a lot your works. Of course the other libraries can help to do specific works and can extend the functionality of the Thread.

You can fork the project and mantain your version, after that you may propose a merge. When they have time surely they will do that. I maintain my version of Indy for example, 'cause their (... his ...) time and priority are not the same as mines.

They are signed that like FIXED in Rad Studio 12.2 PATCH 1.

There are an open issue (an not only one) about that: https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-2144 Seems that the error is about the Visual Assist ... wait for a patch ... (hope for a real patch)....

You can read the sources of Indy to look how it works (with the OpenSSL 1.0.2u, the Indy develop with RAD Studio use this version). Look at guthub repo for more upgrades (https://github.com/IndySockets). Another way is to look how ICS works (https://wiki.overbyte.eu/wiki/index.php/ICS_Download or via GetIt).

This is a example of Manifest of one my Android project, you can edit and adding it (it's indicating with <----- HERE') to your AndroidManifest.XML under Android64 of your project folder: <?xml version="1.0" encoding="utf-8"?> <!-- BEGIN_INCLUDE(manifest) --> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="xxxxxxxxxxxxxxxxxxx" android:versionCode="1" android:versionName="1.0.0" android:installLocation="auto"> <!-- This is the platform API where NativeActivity was introduced. --> <uses-sdk android:minSdkVersion="23" android:targetSdkVersion="34" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.READ_CALL_LOG" /> <uses-permission android:name="android.permission.READ_SMS" /> <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> <uses-permission android:name="android.permission.WAKE_LOCK" /> <uses-feature android:glEsVersion="0x00020000" android:required="True"/> <application android:persistent="False" android:restoreAnyVersion="False" android:label="xxxxxxxxxxxxxxx" android:debuggable="true" android:largeHeap="false" android:icon="@drawable/ic_launcher" android:theme="@style/AppTheme" android:hardwareAccelerated="true"> <!-- Our activity is a subclass of the built-in NativeActivity framework class. This will take care of integrating with our NDK code. --> <activity android:name="com.embarcadero.firemonkey.FMXNativeActivity" android:label="xxxxxxxxxxxl" android:configChanges="orientation|keyboard|keyboardHidden|screenSize" android:launchMode="singleTask" android:exported="true"> <-----------------------------------------------------HERE <!-- Tell NativeActivity the name of our .so --> <meta-data android:name="android.app.lib_name" android:value="xxxxxxxxxxxxxx" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <receiver android:name="com.embarcadero.rtl.notifications.NotificationAlarm" /> </application> </manifest> <!-- END_INCLUDE(manifest) -->

This is the direct link: https://ats.rippling.com/partnerco/jobs/79f36155-18a0-465f-a787-8f2448a55e09 EDIT

I don't have any IDE experts installed (except BCompare), no Parnassus, no getit package except D4P, JCL, JVCL and Indy compiled from github. I removed FIREUILivePreview and EMS components (not compatibles with Indy from github). Except for what I have signaled on QP (AV when switch from Delphi to Mixed Delphi / C++ prj and a Issue with project panel view). I don't have other problems. I used Rad Studio, and switch without close it from Win64 Delphi project and Android Delphi project with debugging either. Changed also the SDK settings (for various release of Android). Always without close the IDE. No issue at all. Like others I'm lucky.

First of all you should know why the file is not deleted. AFter that there are other ways to delete a file, for example when is locked. BUt this go over my competence.

If there are DLL required for python here is the logic, from: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order LOL: I really didn't know about that "The 16-bit system folder. There's no function that obtains the path of this folder, but it is searched."

The midas.a that you have create is a symbolic link (or better a container of symbolik links...) for a MIDAS.DLL and you must deploy MIDAS.DLL with your application. You cannot create a midas.o (or static library) without the source. No chance.

I think should be better that you create the Python engine in a START event of controller, and Free it on Destroy event. Execute method is call more times during the "live" state of Service. Bye

"TokenUser" is a an enum member of TTokenInformationClass defined in WinApi.Windows. You have redefined it in you local variables. EDIT: of course you can use TTokenInformationClass.TokenUser instaed ...

I suggested the same in my previous post

There are lot of packages for Delphi and C++, look at GETIT from IDE and search for: 1) asyncpro or 2) serial I have been using this component for a long time too: https://sourceforge.net/projects/comport/files/comport/4.11/comport411f.zip/download To read the Help you must use an old WinHelp executable. You can discharge it from Microsoft (I had ones for Windows 7 and is working in Win 11). Bye

I don't expect that they change anything and I express explicity that. But I think that signal it is a chance to go better in the future.

Sorry, i mention 16 bit register only for quickly "writing". Of course the implementatio was on 64 bit register. Of the cases you indicated, I have honestly never noticed them (I don't go to debug in assembler unless there is a specific reason). I don't work much with strings, if not merely for the visualizations on the UI and therefore I have not noticed problems such as performance drops or anything else. I sometimes look into assembler, I produce exclusive 64 bit application and no more 32 bit, and I saw that they use tipically REX (so pure 64 bit instruction) and rarely 32 bits instructions (with 32 bit arguments), it may also be that the latter are reminiscences of the past. Of course, for a perfect code as you indicated (and as I would also like it to be) there would be a lot of indications to follow ... in reality I think that the projects (like the compilers) have been carried forward by adding functionality without ever rewriting them from scratch and therefore they necessarily carry with them some legacies of the past. Putting in place all those precautions with which the code could improve both its functionality and stability and perhaps even security is an effort and requires a lot of resources.

I write "really weird" because if you use manually "mov ax, source" and "mov dest, ax" you do it more quickly, and not a little bit. "movsd" and his brothers are complex instructions (like you link): https://uops.info/html-instr/MOVSQ.html The use of them should be carefully considered and evaluated. In the Intel Reference Manual (Intel® 64 and IA-32 Architectures Software Developer’s Manual, - Ed. JUNE 2024) they told about these instructions: So, they should use in these cases (I don't look more deep) to be "fast", otherwise they are "poor" (may think). I don't know if Embarcadero can think (and of course want) and resolve this situation, whether there really is a need to fix it. We try near a bilion of cycles, but it's really a normal situation ? P.S.: I try the same in Lazarus / FPC and the timing is lower (near 400 ms.) for double operations in x64 and their compiler use normal "mov [RBP...], RAX" and company to execute the same work.

I have open an issue to QP: RSS-2192

x64: It's incredible, but writing 3 times in memory is more fast that using MOVSQ ... really weird hardware implementation, may be that this works better with long data, like string. The x32 implements in facts 3 single writing (if datatype is "single") and with "double datatype" use the similar weird approach like x64 with more high timing because it's 2xMOVSD in use.