Leaderboard

To have the Parnassus plugins work in Delphi 12 as well as Delphi 11.3 on the same machine you need to do either of this depending on your situation: Before installing the Delphi 12 plugin: In folder c:\Program Files (x86)\Common Files\ParnassusShared rename ParnassusCoreEditor.dll into ParnassusCoreEditor_XAlexandria.dll After installing the Delphi 12 plugin: Copy the 11 version of ParnassusCoreEditor.dll from the appropriate CatalogRepository folder as ParnassusCoreEditor_XAlexandria.dll into the mentioned folder

Also not true (anymore, it might have been decades ago) - or it might happen that a shifting pointer might be better because of register pressure or shortage under x86 because it only requires one register opposed to two when indexing into an array. But indexing into a memory address with an increasing or decreasing index register is always faster. Another situation might happen when your array is a field of your class and you index into that one because then the compiler is really stupid and re-reads the field every time and then indexes into it. But then the issue is re-reading the field and not the indexing into it. I solved this by putting the array into a local pointer variable and then index into that one - like here. And yet another situation happens on 64bit when using an Integer index variable because then it always does an extra register widening instruction which can be not zero cost (yes, I need to fix the code I just pointed to because it does exactly that having i declared as Integer and not NativeInt as it should be, shoot me). Oh, one particular bad thing about dcc64 is that it does not really optimize some instructions in loops well. From dcc32 we know about the counting down to 0 behavior of a for-to loop where it maintains two counters, the actual index variable (if you actually use that within the loop) and the counting down to 0 variable that it uses to control the loop. For that it usually uses the dec/jnz combination which works well, macro fuses and all that. On win64 it does sub reg, 1, test reg, reg, jnz where only test and jnz fuse which causes wasted cycles. That extra test is complete bonkers because the sub (which should actually be a dec) already sets the zero flag! See RSP-37745 Another missed opportunity of loop optimization that affects both win32 and win64 is letting the compiler create loop that counts from -count to -1 which is another optimization technique where you grab the position after the last element then index into it. This way if you don't need the index variable itself for something else than indexing you only need 2 registers, one points to right after the last element and the loop just needs the nicely fusing inc reg, jnz

Embarcadero knows about it and is working on an official solution. And before someone claims that could have been found during the beta: Most of the GetIt stuff is not available during beta until almost the last day and the majority of beta testers install in a dedicated environment without any prior Delphi version present. Also, not everyone makes use of all what is available in GetIt.

It's presumably a small overhead at process creation

It's likely because you have an incompatible JDK present on the machine. This is a potential fix: 1. Make sure JAVA_HOME environment variable is set to the Adoptium JDK: JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-11.0.15.10-hotspot 2. Add missing build-tools by going to: C:\Users\Public\Documents\Embarcadero\Studio\23.0\CatalogRepository\AndroidSDK-2525-23.0.50491.5718\cmdline-tools\latest\bin In a command prompt and issue these commands: sdkmanager “build-tools;33.0.2” sdkmanager “platforms;android-33”

re: the webinar I wouldn't mind a Youtube video link once it's over.

This is false knowledge - it only does repeated calls to Length when you do for x in some_dynamic_array do loop

In September I restarted my flagship application from scratch and incrementally tracked each increase in file size from bare Win64 VCL app in Delphi 11.1. So I did have a reasonable accounting. I never bought 11.3 as my update subscription expired. I do of course measure performance. This was about EXE bloat. Your posts and scattered internet writings, along with Dalija, Primoz, Arnaud, Remy, and others I am forgetting, have helped me tremendously through the years to learn performant and efficient coding - I am thankful for the dialogue. Let me try my best to contradict your overall practically mostly true argument for my specific case. It is possible to attain optimal performance in Delphi by the mere fact that we have Win64 assembler code ability. Moreover: For SSE2, I use Neslib.FastMath which beats the previous MS D3DX10 DLL SSE-optimized libraries I was using - this is a graphics application and heavily GPU bound due to my excellent, lean, low-level, cache-efficient coding strategies for CPU code possible in Delphi. I am running at 120fps with less than 2% CPU usage in Task Manager with an unfinished app, and am confident I can keep it that way. A C++ app where the programmer has not laid out memory in a cache-efficient manner will have worse performance than a correctly written Delphi Win64 app using FastMath for SSE (packing in to TVector4s) I use inline constants everwhere to pull things into registers and pay attention as much as I can to producing clean assembly with Object Pascal syntax. For instance, I never write for var I := 0 to Length(arr)-1 in hot paths, after I found (admittedly a few versions ago) that it did a repeat call to Length() and/or subtraction - I always go const AHi = High(arr); for var I := 0 to AHI do, etc. If I were using C++ I would have the convenience of trusting that little stupid things like that were already taken care of for me, but the benefits of Delphi for UI design outweight the minor inconveniences. However I know you are right about the overall quality of Embarcadero's compiler which I lament. I greatly lament that Embarcadero has spent more time on Firemonkey/C++/database stuff that's irrelevant to me rather than making a highly optimized Win32/64 compiler and built-in profiling/instrumenting tools. However, this is just a matter of convenience. I still reject that I can't produce as optimal performance of a Delphi Win64 application compared to MSVC, only that it requires much more attention in some areas. Let me know if you disagree with that. BTW - I did decide against the EXE compression libraries for that very reason of their apparent likelihood to trigger AV detections.

I don't know, but I know that GoToWebinar sessions have a limit for the number of participants.

Actually it is running in the moment, but the available seats are all occupied.

I used Charles Proxy to check the request/response for the GraphAPI call from my code (/v1.0/me), and it actually got my profile. But in the Delphi code, the he JSONValue of the response is nil. Here is the code to get the response: FieldRawResponse.Text := TJSON.Format(RESTListResGroupResponse.JSONValue); I also check that RESTListResGroupResponse.content is empty too. Here is the info I get from Charles Proxy

It would make his project fit on 10 floppy disks instead of 35.

And makes your app a target for anti virus products. And what what gain? You end up with the same executable loaded in memory. I've never understood the point of this tool.

It's possible to care about more than one single thing. Personally, I care a lot about performance but I also care about code readability, ease of UI design, and TBH, the amount of fun I have writing the code. If I only cared about performance then I probably wouldn't use Delphi.

The lack of implementing that feature request was the driving force behind writing that article. As long as everybody steps away from designing in High DPI the collected bug reports will only cover the obvious cases but miss the deeper ones. Thus I decided to use the form designer in High DPI for at least one of my projects and see how it goes. Obviously I had to develop a strategy and some workarounds to make it usable in the first place. Publishing it is based on the hope that others also step on that ship and share their findings, too.

You can have this for free: Open MMX properties and navigate to Pascal - Sorting Under Format unit uses clauses check Group and sort uses Now when you format the uses clause (with Ctrl-Alt-U while the cursor is inside a uses clause) MMX does the following: Resolve any unit aliases Resolve all unit scope names Group the units as configured (see below) Compress and wrap each group according to the settings The groups are configured per project in the MMX Project options setting. If the entry for Groups is cleared neither grouping nor sorting is done. Also these Project options have an Auto Format checkbox, which when checked forces the uses clause formatting whenever MMX manipulates a uses clause. My personal preference would be to format the uses clauses without any other changes done to keep version control happy. This can be achieved by a command line tool available on GitHub: UsesCleaner It provides almost the same functionality as MMX, but targets complete projects instead of single units.

Why do you care about these tiny differences in these tiny executables? If you care use Delphi 5.

It better be - I spent quite some time on it. FWIW it was already introduced in 11.3

I've recently updated Indy's GitHub repo to now tag the commits that have been bundled in the past few RAD Studio releases (including 12.0) since Indy switched from SVN to GitHub.

Then please stop using it. Referring to a release by name instead of the version number which everybody recognizes, is just confusing, and everyone, Embarcadero in particular, should just stop doing it. It's pretty annoying having to Google it when someone refers to the name instead of the version number. I haven't bothered with the names since Ivory (see what I mean?). It's bad enough that the version number and build number haven't been in sync since marketing took over and made the numbers "hip" with D2xxx and later XE*

That is literally exactly how Indy is designed to be used. Indy uses blocking sockets and synchronous I/O. Connect() will block the calling thread and not exit until the connection is established. Sends will block the calling thread and not exit until the data has been passed to the kernel. Etc. So, just do exactly what you said above, it will work fine. Just be sure to put the send in a try..finally to ensure the connection is closed even if the send raises an error, eg: IdTCPClient1.Connect; try // send whatever you need... finally IdTCPClient1.Disconnect; end; Most Indy clients are not event-driven. You do not need to wait for the OnConnect event. It is just a status event, not a logic-driving event.

There have been a large number of new features and enhancements implemented in the P4D library recently . This discussion document provides an overview of these developments.

Wich idiot (NOFI) wrote the getit manager? Feels like it's done by some intern? Slow search, Slow scroll, can not queue packages to install at once and go drink coffee. (sorry bad day 🙂 )

DO NOT INSTALL DELPHI 12 ON YOUR PRODUCTION PCS!! this is the result: RAD STUDIO 11.3 KO

The f*king "Search whole words" bug is still here. Unbelievable!