Delphi 10.4.1 and the IDE FIx Pack

[santiago 36]

1 hour ago, Uwe Raabe said:

Are you able to check without Unit Scope Names?

This is how I disabled it (Might be wrong, as I did not find any documentation on this):
 

SET IDEFixPack.DisabledPackages=Compiler.UnitScopeNames

 

In our case it had no impact.

[Uwe Raabe 2057]

The idea was to write all units in all uses clauses with their full names instead of relying on the value in Unit Scope Names.

[dummzeuch 1505]

13 hours ago, santiago said:

In Delphi Compiler Options, UnitAlias is empty.

Is it possible to have UnitAlias empty? When I try that, it automatically gets reset with the ancient aliases for WinTypes etc. But I haven't tried that with recent IDEs.

[santiago 36]

On 10/9/2020 at 1:35 AM, dummzeuch said:

Is it possible to have UnitAlias empty? When I try that, it automatically gets reset with the ancient aliases for WinTypes etc. But I haven't tried that with recent IDEs.

This is how it looks like for me (Delphi Rio 10.3.3).

Unit Aliases is something I have never needed to use so far.

[jbg 239]

The UnitFindByAlias name is misleading. It doesn't have anything to do with Unit-Aliases. I took the name from the compiler's jdbg file. A much more describing name would be FindUnitByUnitName, because that is what the function actually does.

[Lars Fosdal 1792]

There are a number of libs, such as TMS, that still do not use fully qualified unit names.  
We removed as many aliases as possible, but could not remove them all.

 

As for the problem being discussed - is it the same as this one: https://quality.embarcadero.com/browse/RSP-18130?filter=-2 ?

 

Edit: We use 10.4.1 now, and although the compilation still is sluggish - we wait a lot longer for the EurekaLog linker to complete its task than we do for the actual compiling.

[Uwe Raabe 2057]

51 minutes ago, Lars Fosdal said:

There are a number of libs, such as TMS, that still do not use fully qualified unit names.  

You can make use of pre-compiled DCUs for these libraries.

[Lars Fosdal 1792]

1 hour ago, Uwe Raabe said:

You can make use of pre-compiled DCUs for these libraries.

We could, but we have our reasons for not doing so.

[santiago 36]

On 10/8/2020 at 4:44 PM, Uwe Raabe said:

The idea was to write all units in all uses clauses with their full names instead of relying on the value in Unit Scope Names.

Now I follow you 🙂

This is very actually very interesting. This is how the 'Unit Scope Names' settings look for our projects.

If I understand correctly, the fewer unit scopes that are defined here, the faster the project will compile. Correct?

 

I am certain we don't need all those entries. I guess no one has ever looked into it until now.

Anyhow, I will try to eliminate the need for using Unit Scope Names.

 

[santiago 36]

I cleaned up one project (40K lines of code, ca. 80 units, depends on 21 projects).

I cleared the 'Unit Scope Names' from the Project Options to be empty.

I had to fix many compile errors (in 47 units) by using the full scoped name (e.g: System.SysUtils, instead of just SysUtils).

 

Delphi Rio 10.3.3 (WITH IDEFixPack)

Before the changes this project compiled in ca. 8 seconds

After the changes it improved slightly to: ca. 7.7 seconds

 

Delphi 10.4.1

Before the changes: ca. 11.5 seconds.

After the changes: 8.7 seconds.

 

Delphi Rio 10.3.3 (WITHOUT IDEFixPack)

Before the changes: 18.1 seconds

After the changes: 14.5 seconds

 

Ideally you should always use the fully scoped names.

I would have never had thought that this would have such an impact on compile time...

[Jacek Laskowski 57]

On 9/21/2020 at 10:36 PM, Remy Lebeau said:

Correct.  Andreas has already gone on record stating that he no longer has a license to paid versions of RADStudio and so will not be able to update IDEFixPack for new IDE versions without their Community Editions.  And Embarcadero has already gone on record stating that releasing a 10.4 Community Edition has been delayed, with no ETA stated as of yet.

Sarina DuPont, comment from 5 months ago:

 

"10.3.3 versions of Delphi and C++ Builder Community Edition remain available for download. 10.3.3 was an excellent release and Community Edition users can perfectly well continue to work with that release. 

The majority of customers who need the best performance, quality and features should be able to purchase the latest release. Our paying customers deserve a premium experience. That, coupled with increased non-compliant usage of Community Edition (which we're actively addressing with our legal team), has resulted in delaying a new release of CE. Over the coming months, we'll determine when a 10.4 version of CE will be released. 

 

Regards,

Sarina"

Edited October 15, 2020 by Jacek Laskowski

[Remy Lebeau 1398]

8 hours ago, Jacek Laskowski said:

Sarina DuPont, comment from 5 months ago:

Yup, and here we are, months after the initial 10.4 release, and already into a new 10.4.1 release, and Embarcadero still hasn't stated one way or the other if they are even working on a Community Edition or not, let alone an ETA for it.

[Uwe Raabe 2057]

 

8 hours ago, Jacek Laskowski said:

Our paying customers deserve a premium experience.

Well, this suggests there will never be a CE for the current version, only for previous versions. This implies that there will be no Fix-Pack for any current version either.

[Stéphane Wierzbicki 45]

9 minutes ago, Uwe Raabe said:

 

Well, this suggests there will never be a CE for the current version, only for previous versions. This implies that there will be no Fix-Pack for any current version either.

And that is a shame...

[Uwe Raabe 2057]

26 minutes ago, Stéphane Wierzbicki said:

And that is a shame...

Perhaps, but one should not forget that Embarcadero actually did offer a full version for free to Andy several times. Even if that version may be time limited for one year, that is just the same with the CE version anyway. So he may have his reasons to decline these offers, which we simply do no know.

[FredS 138]

2 hours ago, Uwe Raabe said:

that version may be time limited

 

I guess the key point is that Embarcadero is just fine without the fix pack then.. move along..

[Stefan Glienke 2006]

tbh not having IDEFixPack being available is good in the long run - with the existence of it nobody (or very few) actually cared to report issues and put some pressure on Embarcadero to address these things. Now that there is no solution available the pressure on Embarcadero has raised and I can confirm that they are working on it - will they suddenly implement all fixes and optimizations from Andreas? No, but better they do slowly than relying on the third party no matter how incredible.

Edited October 16, 2020 by Stefan Glienke

[aehimself 396]

On 10/16/2020 at 10:52 AM, Stefan Glienke said:

No, but better they do slowly than relying on the third party no matter how incredible.

And this is fine, unless a significant amount of them will never be looked at, and just forgotten when 10.4.2 comes out.

Afaik, there are bugs what Delphi is carrying for more than 5 years.

[FredS 138]

16 hours ago, aehimself said:

unless a significant amount of them will never be looked at

 

Yup, this thinking suggests that all those usability, compile and stability issues where fine as long as Andy fixed 'em..

 

[Stéphane Wierzbicki 45]

1 hour ago, FredS said:

 

Yup, this thinking suggests that all those usability, compile and stability issues where fine as long as Andy fixed 'em..

 

I do not fully agree. I was able to live without IDE FixPack until XE area, when unit scope was introduced. At that time IDE were barely usable, took a lot of time displaying forms at design time, compiling project (the more directories in the search path the worse the IDE react)...

[FredS 138]

24 minutes ago, Stéphane Wierzbicki said:

the more directories in the search path the worse the IDE react

 

For sure. Executing a cmd which deletes DCUs that may have been compiled using different config seems to have helped a lot.

 

I didn't come back until XE7 (D6->XE7) at which point there where huge issues with or without fix pack. The interesting part is that some of those got better with one minor release then came back in the next..

 

 

[santiago 36]

On 10/8/2020 at 4:54 AM, Marco Cantu said:

We also have another not in the fix pack that we are rolling out early in a patch, affecting unit cache for large projects and causing compiler time to grow (dramatically!) over successive builds

 

Marco,
do you have an estimate when this patch will become available?
I would like to give 10.4.1 another try. Currently we are still on 10.3.3.