Why is public class method marked as used, while it's not actually used?

[Mike Torrettinni 198]

47 minutes ago, Lajos Juhász said:

IMHO nobody should expect the IDE will keep which method is where used (especially if you have a project with thousands of units).

Is this true? The 'blue dots' are relevant after compile is done, so 1 unit or 1000s of units inproject, after compile IDE should know what's used and what not, right? Of course referring to local units, not packages or dlls...

[A.M. Hoornweg 144]

1 minute ago, David Heffernan said:

If you really want to reduce the size of what you deploy then use runtime packages instead of DLLs and you won't duplicate RTL/VCL classes. Likely that would save you far more than you would save by stripping RTTI in the RTL/VCL code that you link, were it even possible for you to do that.

Packages aren't possible in this project unfortunately. I've tried it but there were too many issues.

 

 

For the time being I still deploy using Delphi XE, using a recompiled version of the RTL and VCL that has most of the RTTI stripped out.  But soon I must move everything over to Delphi 10.4 Sydney and I'd really like to find a way to reduce binary size.

[David Heffernan 2345]

3 minutes ago, A.M. Hoornweg said:

I'd really like to find a way to reduce binary size

Using packages would achieve that

[Dalija Prasnikar 1396]

35 minutes ago, David Heffernan said:

If you really want to reduce the size of what you deploy then use runtime packages instead of DLLs and you won't duplicate RTL/VCL classes. Likely that would save you far more than you would save by stripping RTTI in the RTL/VCL code that you link, were it even possible for you to do that.

Runtime packages are not always ideal solution, so you have to weight your options.

 

Just for fun... my installer application written in D7 is 1.1MB, same code recompiled in XE4 is 3.5MB, 10.4 4.7 MB.  Windows 32bit

 

Of course, no DLLs here... but even if you can argue that there are substantial differences and needed improvements between D7 and XE4, between XE4 and 10.4 when it comes to VCL new features were sparse, and certainly not large enough to justify size difference. I mean the whole darn setup in D7 with several forms fits into that difference (XE4-10.4)

[A.M. Hoornweg 144]

18 minutes ago, David Heffernan said:

Using packages would achieve that

Packages don't work in this constellation.  No really, they don't.

[bobD 6]

15 minutes ago, Mike Torrettinni said:

Is this true? The 'blue dots' are relevant after compile is done, so 1 unit or 1000s of units inproject, after compile IDE should know what's used and what not, right? Of course referring to local units, not packages or dlls...

The blue dots indicate that code was generated for that line, not that that code is known to be called. It's 'used' only in the sense that the compiler used it.

For a public method, knowing for sure that a public method is not used would entail inspecting the implementation code for all other units in the project; the class might appear in an implementation uses clause, so just reading all the interface sections wouldn't do it..

So Delphi would have to be rearchitected as a multi-pass compiler to optimize the code at that level, inspecting and cataloging the entire code base before compiling anything.

Said more simply:  while you can know what's used and what not, the compiler has no way to know that at the time it's compiling the unit.

[David Heffernan 2345]

14 minutes ago, A.M. Hoornweg said:

Packages don't work in this constellation.  No really, they don't.

Packages do work. If you can't make them work in your setting, that's probably more a statement about the constraints that you are imposing.

[Mike Torrettinni 198]

13 minutes ago, bobD said:

So Delphi would have to be rearchitected as a multi-pass compiler to optimize the code at that level, inspecting and cataloging the entire code base before compiling anything.

Would be nice. Can you imagine how long it would take Embarcadero to implement this? 🙂

[A.M. Hoornweg 144]

17 hours ago, David Heffernan said:

Packages do work. If you can't make them work in your setting, that's probably more a statement about the constraints that you are imposing.

That may very well be so. But in my particular constellation they do not work and I'm not going to try again.

 

Edit:

 

Let me illustrate one of the many many problems I stumbled upon. 

 

Assume you develop some COM DLLs and some applications as independent projects and you wish to compile everything with packages, just for the sake of saving footprint.  Also assume that some of these DLLs have visual dialogs, using third-party components (LMD, TMS etcetera). 

 

The unintentional side effect of this constellation is that the DLLs and the application share global variables in memory, such as the "Application" object. 

 

Without packages that would not be the case.  If any DLL manipulates events of tApplication in its initialization process, such as setting "Application.OnMessage:=SomeMethod", that is a protection fault waiting to happen, because as soon as the DLL is unloaded from memory by the operating system that event will point to an invalid memory location whilst tApplication is still "live".  And a lot of third-party visual component libraries do this unfortunately.  In my case, the DLL's are COM dll's and the operating system loads/unloads them dynamically. 

 

Edited November 11, 2020 by A.M. Hoornweg
example problem