The IDE Fix Pack 6.0 BETA for XE2-10Seattle focuses on the Win64 compiler’s compile speed. It not only uses SSE2-SSE4.1 instructions to increase the compiler’s performance but it also optimizes for the most common cases. Micro optimizations are used for tight loops and functions that are called a million times.
Even with this patch the Win64 compiler isn’t on par with the Win32 compiler’s speed, but the difference isn’t that huge any more and there are still some possible optimization. But it takes a lot of time to analyze those and write the patches. And I if I would hold back the version 6.0 till all of those are completed, you will never see a version 6.0.
Because those changes to the compiler may intro bugs, I’m not releasing a gold version but a BETA version. That means that this isn’t meant for production use.
Don’t forgot: I’m not Embarcadero and I’m not fixing somebody’s pet bug. This BETA is all about the Win64 compiler speed optimizations. So please don’t report bugs (in the comments, at Google+, email) that aren’t related to the Win64 compiler speed optimizations. If the compiler outputs defect code with and without my patches, I won’t (and can’t) help you.
BETA Download:
| Name | IDE Version | File | Size | Downloads | Added |
|---|
Hello,
Thanks for all your great work. Do you have a spot that we can report bugs?
You can report them in the comments here or in the comments in Google+ or write me an email. But I hope there aren’t any in the Win64 compiler optimizations.
We have a bug that seems to exist in the previous few versions of IDE fixpack since 5.8 (the earliest I noticed it) and persists in the latest beta. We are using Delphi XE7 Update 1.
If you compile our application in 32 bit with IDE fixpack on or off it compiles fine (although much faster if its on). If you compile in 64 bit without IDE fixpack it compiles fine (albeit quite slowly, it takes about 5 minutes to compile). If you compile in 64 bit with IDE fix pack we get
[dcc64 Fatal Error] Signature Unit.pas(213): out of memory. It used to compile fine and took just 2 minutes.
If it very consistent on that line of code, even though that class is perfectly fine and compiles in all other cases described above. Strangely, sometimes if you just change the unit a bit (i.e. adding a blank line, reordering some of the variable declarations) you can get it to compile. But maybe the next day, or on another developers machine, it wont compile any longer.
If you are interested in pursuing this, I can arrange for you to have access to a VM with our infrastructure setup , please just contact me directly at the email address that I submitted with this post. I have no simple reproduction case. Our program is > 1M lines of code with fairly heavy use of generics, anonymous methods etc (although the class it it dying on is quite simple) so I have no way to simply reproduce it for you.
Hello,
We have the exact same bug since we migrate to Delphi 10 (seattle) and the last stable IDE Fix pack.
We get a out of memory error when compiling in 64 bits, always in the same file and same line.
The package is about 95 000 lines and 5Mo of code.
I’ll try to reproduce the case in a small project to send it to you.
XE2 is unsupported, but in case anyone else does see something similar.
It hangs (probably forever) while compiling a project with nothing but FastMM4 for Win64 with the XE2 IDE, while it compiles with XE6 and 10 Seattle. I have tried to compile XanaNews for Win64 and could repeat it with an empty project.
I may drop the XE2 support for those patches because XE2 is the only version for which I had to add $IF conditions. All other Delphi versions don’t need $IF conditions (what means that the code snippets that I patch haven’t changed since XE3).
Should be fixed now. I just disabled even more patches. (and the ImgList patch is also included)
I can confirm both. Thanks!
“Don’t forgot: I’m not Embarcadero and I’m not fixing somebody’s pet bug.”
Really? I heard you are!
Hi Andreas,
thanks for your continuous support of the IDE.
Merry Christmas!
Any benchmark results ?
Hello Andy
first of all: Great job!
We do have some external build scripts for our products and I switched one of them to the new BETA 6.0.
Embarcadero Delphi for Win64 compiler version 30.0
1003418 lines, 45.69 seconds, 27003712 bytes code, 2020160 bytes data.
Compiler Speed Pack – Compiler patches applied.
Embarcadero Delphi for Win64 compiler version 30.0
1003418 lines, 24.71 seconds, 27003712 bytes code, 2020160 bytes data.
gives pretty much a feeling on the speed increase!
best regards and happy new year
Günther
Does EMBA know about that patches? Why do we have still bottlenecks with every new compiler release?
If they read my blog, or follow my Twitter account or read the announcements on Google+, then they would know. Otherwise: No.
> Why do we have still bottlenecks with every new compiler release?
Because it may be a business decision or lack of man power or both to not make the compilers faster. Supporting many platforms can bind a lot of man power.
I fear, I have to wait for Delphi 20.
You are “one” person!? I understand, you are equal to 10 men (power) 😉
Hi Andy, if I may, here a bug report on IDEFixPackXE2Reg60beta2 (applied to Delphi XE2 16.0.4358.45540);
When I compile my 64 bit app with it, my application crashes on the first call to VirtualAlloc (from System.InitUnits > GetMem > FastMM4 AllocNewSequentialFeedMediumPool). The CPU View shows this call overwrites the returnadress on the stack with $14000, resulting in a non-recovarable application crash.
Switching back to IDEFixPackXE2Reg594 fixes this issue.
Regards,
Patrick
That’s why it is a BETA version. And my feeling tells me that I should disable all 6.0 patches for XE2 and XE3 as both seems to have too many differences to the XE8 compiler (the one that I did my research on and used to implement the patches).
it works on my rad xe4 within windows 10, but unfortunatelly all third party components are missing, how do i restored those components?
Thank You
What do you mean with “all third party components are missing”? IDE Fix Pack doesn’t make your components vanish.