IDE Fix pack for Rio

[Syntri 0]

Does anybody know if there wil be Rio support for the IDE fix pack?

[Markus Kinzler 174]

I guess only @jbg can anwer this question.

[Fred Ahrens 59]

Deep in the release notes I have seen some comments regarding the implementation of some of Andreas' patches directly into the official release. But I couldn't find any further info if this is the full feature set of the Fix Pack or only a few selected patches.

[Uwe Raabe 2064]

27 minutes ago, Fred Ahrens said:

the implementation of some of Andreas' patches directly into the official release

I can also vaguely remember that Andreas claimed that as the reason why there will be no IDE Fix Pack for Rio. Unfortunately I cannot find that statement anymore, so it should be taken with care.

[ŁukaszDe 38]

Without IDE Fix Pack projects compile twice as long.

[Markus Kinzler 174]

He mentioned that his subscription was running out.

[Syntri 0]

23 minutes ago, Markus Kinzler said:

He mentioned that his subscription was running out.

With the new community edition this shouldn't be a problem.

 

27 minutes ago, ŁukaszDe said:

Without IDE Fix Pack projects compile twice as long.

I can second that. It takes double time.

[David Heffernan 2353]

35 minutes ago, ŁukaszDe said:

Without IDE Fix Pack projects compile twice as long.

You can't know that because IDE Fix Pack does not exist for Rio. 

[ŁukaszDe 38]

If IDE FIx Pack significantly reduced the compilation time of the project in XE2 and 10.2.3, it probably will do it also in 10.3 (the same project).

 

In the subject:

RSP-21934

Edited December 4, 2018 by ŁukaszDe

[Rollo62 539]

As far as i understood EMBT, the IdeFixPack should be partly Integrated.

Is there still tve need for the rest ?

 

[Sherlock 663]

In http://docwiki.embarcadero.com/RADStudio/Rio/en/What's_New see the chapter "Fix Pack improvements":

Quote

Fix Pack Improvements

RAD Studio 10.3 Rio includes some of Andreas Hausladen's “IDE Fix Pack” fixes and improvements. Most of the incorporated fixes are focused around the IDE and include the following:

• High resolution timer caused by using Virtual Treeview.
• FindHInstance optimisations.
• Debugger using CREATE_DEFAULT_ERROR_MODE when creating the process.
• TStringList IndexOf and Name optimisations.

So nothing connected to the compiler. Way to go that extra mile, EMBT.

[Syntri 0]

7 minutes ago, Rollo62 said:

As far as i understood EMBT, the IdeFixPack should be partly Integrated.

Is there still tve need for the rest ?

 

Yes, as ŁukaszDe says, building takes a lot (2 or 3 times) longer as Tokyo with the FixPack.

[David Heffernan 2353]

1 hour ago, ŁukaszDe said:

If IDE FIx Pack significantly reduced the compilation time of the project in XE2 and 10.2.3, it probably will do it also in 10.3 (the same project).

 

In the subject:

RSP-21934

Assuming that the integration of IDE Fix Pack doesn't address compiler performance. Which it might. Or might not.

 

Easy enough to compare 10.2 and 10.3 rather than guessing. 

[Kryvich 165]

I measured a time to build the camera_shake.dpr project from TERRA-Engine framework in Delphi 10.2.3 and Delphi 10.3. TERRA Engine is a complex cross-platform engine, known for its cyclic unit references, and freezes in IDE.

 

Camera_shake.dpr project build time, Windows 32-bit platform:

• Delphi 10.2.3 with IDE Fix Pack 6.3.1, Compiler Speed Pack x86 / x64 6.3.1 -- 06 min 59 sec.
• Delphi 10.3 -- 06 min 33 sec.

I measured the time on my phone manually, so there may be some error.

[sakura 45]

I have similar results. The compiler on 10.3 is faster without any FixPack, than the compiler of 10.2.3 with the FixPack installed. So, I am fine with that part.

 

... 🐈 ...

[ŁukaszDe 38]

My project.

The time of compilation with and without IDE Fix Pack is very different.

 

10.2.3 with IDE Fix Pack

 

10.2.3 without IDE Fix Pack

 

10.3

 

XE2 with IDE Fix Pack

 

XE2 without IDE Fix Pack

 

CnPack Source Statistics from: 

XE2

10.2.3

10.3

Edited December 6, 2018 by ŁukaszDe

[Kryvich 165]

Well, I'm sure Andreas Hausladen could improve the result for 10.3 anyway.

[Stefan Glienke 2019]

The patches that went in 10.3 are mostly IDE related and not compiler related afaik.

Also from a few comments about the progress dialog alone affecting the duration of the compilation I have the strange feeling that inside the IDE the progress callback is wired a bit wrong (synchronous instead of asynchronous) causing unnecessary extra slowdown.

[jbg 239]

41 minutes ago, Stefan Glienke said:

Also from a few comments about the progress dialog alone affecting the duration of the compilation I have the strange feeling that inside the IDE the progress callback is wired a bit wrong (synchronous instead of asynchronous) causing unnecessary extra slowdown.

Unless you use the external compiler, the compiler runs in the main thread and every time it updates the progress dialog it "pauses" the compilation. IDE Fix Pack reduces the slowdown a little bit by only updating the UI after a certain time interval or a filename change, thus not every "compiled lines" update repaints the UI.

 

Quote

The patches that went in 10.3 are mostly IDE related and not compiler related afaik.

There are changes in the 64 bit compiler (e.g. some loop unrolling)

Edited December 6, 2018 by jbg

[Stefan Glienke 2019]

4 minutes ago, jbg said:

compiler runs in the main thread and every time it updates the progress dialog it "pauses" the compilation

*facepalm*

[Uwe Raabe 2064]

17 minutes ago, jbg said:

Unless you use the external compiler, the compiler runs in the main thread

I hope that is also not the case when background compilation is enabled.

[Tommi Prami 131]

I believe Embarcadero acquired rights to Ide FIX pack and changes are added to IDE it self, embarcadero only knows which ones and how tough...

 

Andy is now trying to make DDevExtensions for Rio, but had some problems with debugging Ide bpls, I think I saw tweet yesterday.

 

-Tee-

[Markus Kinzler 174]

 

[Arnaud Bouchez 407]

16 hours ago, jbg said:

There are changes in the 64 bit compiler (e.g. some loop unrolling)

Where this information came from?
If it is the case, I didn't see any performance enhancement at execution, at least from our mORMot regression tests, which run a lot of performance measurements.
In fact, most loop unrolling could even be slower on modern CPUs - for instance, AES unrolled loop which was faster on P4 is slower than a tuned rolled loop.
I doubt EMB did make proper compiler optimization in loop unrolling, and let the inlining performance problems remain.

[jbg 239]

2 hours ago, Arnaud Bouchez said:

Where this information came from?

The code optimizer didn't get a loop unrolling feature.

 

In the compiler's own code there are now some loops unrolled, that IDEFixPack used to replace by SSE instructions. The performance gain is not measurable but the IDEFixPack compiler patches couldn't find the function's memory addresses anymore.

 

for I := 0 to 3 do
  A[I] := 0;

became

Zero := 0; // clear one CPU register for all the assignments, instead of clearing the same cpu register for every line.
A[0] := Zero;
A[1] := Zero;
A[2] := Zero;
A[3] := Zero;