PaulM117

I have setup my project to compile with today-released Delphi 12 Athens and existing Delphi 11.1 Alexandria. 1. This is an absolutely ceteris paribus comparison (same project, same code, same compiler options, same linker options) 2. I compile my application in Win64 Release on Delphi 12 - 15.0mb 3. I immediately thereafter compile the same exact application/project/config in Delphi 11.1 - 14.7mb Does anybody know what Embarcadero did to explain the difference? Based on all the info released on Delphi 12, I do not see any reference to core RTL changes that would explain this difference. I know "it's only 0.3mb", but the problem is it's a 0.3mb that shouldn't be there if I am doing the exact same thing with the exact same versions of libaries, the exact same code, and the exact same compiler options. Do you think when new versions of Microsoft Visual Studio C++ get released that such a thing happens? To me this is only acceptable if the announced version upgrade changes include a disclosure about core RTL changes that would cause a reasonable person in my shoes to understand why and where the bloat is coming from. For only code, 0.3mb difference seems hard to justify. Does anyone know where this is coming from, based upon what's been disclosed so far? I did not find on the Embarcadero website today a link to a wiki-style documentation page listing all of the Delphi changes in-detail from 11.3 where I can review RTL improvements. Has such a listing been released yet as for previous versions?

I need to recheck this behavior in 12. Maybe it was just the extra subtraction, but I swear I saw in the assembly there was some ridiculously omitted basic optimization/wasteful output. Probably was 10.4. In general things like this have cultivated a very helpful distrust of the compiler. OK, here's another one you will probably agree with. In C++, most compilers will take simple loops linearly iterating over an array and omit the re-indexing computation by incrementing a pointer. But I always have to go var pFirstItem := PInteger(@IntArr[0]); for I := 0 to IntArrHigh do begin pFirstItem^ := something; Inc(pFirstItem); end. With this kind of attention as a common practice, I really wonder how much performance in the low-level assembly code I am missing as compared to MSVC. My belief that memory layout and cache usage efficiency are orders of magnitude more meaningful seems to be supported by recent industry experience, books, talks, articles, trends, etc. I'm part of the whole "Data Oriented Design" religion and Delphi allows me to do this well.

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.

User perception and optimization of robust tactical deployment of application to Win64 targets (minimal bandwidth/file IO usage). Admittedly, EXE size is a comparatively small factor to these stated ends when compared with runtime performance. It's necessary though that I at least know what is occupying the size. I need to be able to reason about the contents of the binary file and ensure there is no major waste or unknowns. Instruction cache effects could also theoretically impact performance negatively with larger EXE sizes, could they not?

Thanks both for your input. The most meaningful answer is that, as you pointed out Stefan, I could diff the RTL directories and examine myself. I'd be curious to hear of any other RTL changes that might be significant for the developer of a performance-critical Delphi 11.1 app to know about when upgrading. The full wiki bugfix list is helpful and I am currently pouring over that. Hopefully I can finally get rid of my custom FastMove routine I copied from someone's suggestion on the quality report site and assume that the built-in Move() is now as optimized.

My past posts here or elsewhere (can't remember) complained about the quality of Delphi 11.1 where I faced a constant onslaught of F2048 errors, compiler freezes, and a frustrating peculiarity where the 64-bit debugger simply would not work - breakpoints were blank as if release mode - when the 32bit worked fine, and a 64-bit empty project worked fine. I absolutely knew it was a legitimate Delphi 11.1 bug and not my fault of configuration, and I even had now-proven-true inklings it related to usage of modern language features. It got so horrible with Delphi, having to do a full rebuild of source for even the smallest source edits or else face an IDE hang, that I had to restart my project (2014--2023 codebase) from scratch and start rebuilding from square one. The 64-bit debugger worked fine on the empty project, so I knew I would find the culprit eventually. I have now isolated two code snippets that repeatably determine whether the 64-bit debugger is nuked. It's from merely including the otherwise very useful TypeInfo() compile-time special magic object. Please let me know if a workaround for this because Delphi truly and sadly lacks C++'s compile-time and static polymorphism/record type initialization features, and TypeInfo() was the closest one could get. The following code causes Delphi 11.1 to have a completely dysfunctional Win64 debugger: procedure TStackListWordMaxLength<T>.Erase(const N: Word); begin const Pos = N*NumFields; const WriteAddr: NativeInt = NativeInt(Data)+SizeOf(T)*Pos; if TypeInfo(T) = TypeInfo(Byte) then PByte(WriteAddr)^ := FreeElement else if TypeInfo(T) = TypeInfo(Word) then PWord(WriteAddr)^ := FreeElement else if TypeInfo(T) = TypeInfo(Integer) then PInteger(WriteAddr)^ := FreeElement; FreeElement := N; end; The following identical code with mere 3 lines commented-out (i.e., made completely dysfunctional) restores the 64-bit debugger to normalcy: procedure TStackListWordMaxLength<T>.Erase(const N: Word); begin const Pos = N*NumFields; const WriteAddr: NativeInt = NativeInt(Data)+SizeOf(T)*Pos; //if TypeInfo(T) = TypeInfo(Byte) then PByte(WriteAddr)^ := FreeElement .//else if TypeInfo(T) = TypeInfo(Word) then PWord(WriteAddr)^ := FreeElement //else if TypeInfo(T) = TypeInfo(Integer) then PInteger(WriteAddr)^ := FreeElement; FreeElement := N; end; Nobody ever mentioned this bug as far as I've seen. Is it previously known? How else am I supposed to implement a generic stack-memory-allocating-first list of various ordinal size, without manually copying different versions of a non-generic struct, and also have a working Win64 debugger?

Wish I had seen this thread before wasting hours configuring 11 on my new dev PC only to discover it was 11.0 and I need 11.1. Delphi 11.0 IDE routinely freezes on F9 compiles on 11.0 and the situation is only a little better on 11.1. Full recompiles are still needed often, but at least I will get an F2084 Internal Error on 11.1 instead of a whole crash. See my thread I made a few months ago. Embarcadero is doing a great job of making 15+ year veteran developers hate them. How unethical and outrageous for them to rescind the link to a product I paid for, not mention anywhere this surreptitious recent practice designed to fatigue and deceive people into purchasing an update subscription, leave a misleading website error page in its place, and require me to waste my time contacting them for the link to "RADStudio_11_1_5_esd_10253.exe"

The alleged "quality focused update" of Delphi 11.3 Professional, which Embarcadero wants to charge me $850 for despite the fact that I already own Delphi 11.1, has represented an utter disaster of usability and product quality to me further indicative of the decline of Delphi IDE's competency and stability in the past years rather than improvement. I am afflicted by a perpetual state in which even the most minor one-line source edits (even changing a constant number like "2" to "1" in an arithmetic statement) forcibly requires me to do a time-consuming full "Build All" or else I will get repeatable, infinite "dcc32 Fatal Errors" and "F2084 Internal Errors" which are 100% the fault of Delphi. At least in 11.1 I could usually do an annoying "Clean" + "Compile" workaround; this is even worse in 11.3. This seems to affect my newer source code units (where I am working) but happens less frequently in older source units. I have tried, to no avail: 1. Changing encoding from ASCII to UTF-8 2. -cleanregistryide directive 3. Uninstalling GExperts 4. Messing with the "use MSBuild external compile" option (which was already on) 5. Ensuring that IDE memory consumption is minimal (it's WAY under the threshold where it changes cache behavior) 6. Ensuring "Enable unit directory cache" is enabled This insane problem has cratered my productivity and utterly annihilated the one major benefit Delphi has over C++ which is fast compile times, because I have to do a full build every time. Yet Embarcadero has the audacity to want to charge me $850 for a minor subversion upgrade where I could have started clean and fresh with MS Visual Studio / C++ for absolutely free even for commercial use. The remaining and degraded issues in 11.3 are not only the broken compiler. Does anyone else experience the following: 1. The Win64 debugger totally stopped working for me months ago even on 11.1. No breakpoints work; they appear Xd-out as if compiled in release mode or as if placed in an inline function. Win32 debugger breakpoints work fine. 2. The inline constants/vars display in the debugger is totally broken showing false values that are not identical to the actual values of inline vars actually running in code (still not fixed in 11.3) 3. Uniquely to the difference of 11.1, I have witnessed in 11.3 multiple examples of minor code changes in saved Pascal unit files not correctly updating/generating new code upon a rare successful "Compile" (I can rarely use quick "Compile" and not a full build in old source units, like I mentioned above), and rather I have to force a full rebuild to effectuate these changes. This never happened in 11.1. I.e., it's possible to make code edits in 11.3, and get a successful compile, that never actually changed the binary compiled code in those areas. 4. Frequently the entire IDE will freeze on a competent $2k 2021 Asus Expertbook laptop during compilation and I must terminate in task manager and restart the whole IDE. This rarely happened on older versions. The way the Delphi IDE freezes is unique; it does not trigger the Windows "this program is not responding" dialog. It's almost as if it's using the Win32 API window disable flag to simulate a complete freeze while giving the user false hope the compiler is just doing a hard part and will return temporarily. 5. Code generation and optimizations are still extremely lacking in dcc32/64 compared to industry standard C++ compilers. What an embarassment! Why do we have to live with such Stockholm Syndrome here to the point that Embarcadero brags about how optimized their Move routine is in 11.3 (when it was actually just completely horrible before, and still is apparently not as good as C++ implementations). Very frustrating that my reversion to 11.1 makes it apparently impossible to use the new faster Move routine in built-in RTL operations, since I was totally unable to recompile System.pas when I altered it with the new Move. Any experience, information, help, or fellow developer commiseration on the current state of Delphi 11.3 is welcomed and solicited.

Thanks for the responses, particularly to David and Dalija, whose printed and internet-published educational works have greatly aided my Delphi expertise throughout the years. I have data suggesting 80% of the theories and recommendations in this thread are certainly non-responsive and that what I am experiencing is indeed a unique compiler issue limited to certain "cursed" newer source files which do not differ in language feature usage from other older source files which do not exhibit this problem (I had thought perhaps using things like generics, inline vars, or inline function directives, or something like that, could trigger this, but this is not identifiable in my codebase between smaller, new units repeatably triggering this issue and larger, older source units which do not). The other 20% of feedback in this thread (particularly, some of Lars's points) gives me some homework to do before I post a more rigorous reply here trying and discounting theories. Of note, I reverted to 11.1 and the same issue does exist. However, the full build seems much faster in 11.1 than in 11.3 and the repeat freezing/crashing-mid-full-build issue seems much worse/more common in 11.3, so 11.3 is still a downgrade for me even while admitting that the gravamen of my thread (the full-build-requiring condition on some magical "cursed" source units from de minimis source changes thereto but not on others) is an issue that precedes 11.3.