ventiseis

Delphi provides two uses clauses in every unit. The discussion, which uses clause is to be preferred, seems to be an old one. There are different justifications which unit clause should be used – regarding code style, circular references, or readability. The information I am missing is: in terms of compilation time and memory use – where should I put my units if I am free to decide? Is there a general rule for all Delphi versions or is the behavior different in different versions? I do not know of an official statement from Embarcadero, but I tend to think that putting everything in the interface clause should improve compilation time and memory usage in the IDE. I do not want to start another discussion about code style and which uses clause to prefer – this was already discussed at length at other locations. I want to reduce compilation time and memory use in large projects.

I think this is a very useful link. Thank you, I didn't notice it before. I would appreciate it if such information were provided by the official documentation ("docwiki").

I also think that this a major advantage of putting all dependencies into the interface section- you are "forced" to write cycle-free dependencies. Side note 1: Of course I tried the avaliable tools to detect cyclic dependencies (if there are any) - but the last time I tried they didn't work as well as expected: conditional compilation with compiler directives or generics lead to parser errors in this tools. Side note 2: I don't think that there is an official statement in the documentation which warns you about these cyclic references... The only thing I could find is the following: Is that misleading?

I understand your points and I will be happily convinced to use another dcu output path. But back to the original question: can we reduce our memory usage by the compiler if we follow a specific strategy with the uses clauses? Does the afore mentioned tracking of dependencies between included units in the interface uses clause increase memory consumption? From a naive point of view, the compiler must compile each unit at the first build - regardless of the order of the units. And I would assume that the binary result is cached somehow in the memory, leading to the high usage. Another thing which I do not want to include in the discussion are the uncertainties with unit initialization order which is derived from the uses order of units in the uses clause.

Just for explanation: we use subst to have the identical paths on every dev machine. Before that, a ram drive was used for that - but in newer windows versions they seemed problematic, too.

There is one thing that the documentation states: This would support your statement. But this behaviour is broken in our environment: if I compile the same project twice, every single unit is compiled again to dcu - even if I do not change a single line of code! We use an alternative dcu output path in the project options. It is a virtual drive created by the subst utility. If I remove that virtual drive and set the dcu output path to a different path, the documented behavior works again - i have no explanation for this.

Of course there is no proof -- but for one project I moved the uses clauses to the top in a lot of units and got approx. 1s less build time (which is not much). This project (now) consists of 1182 units and ca. 1.700.000 lines of code. The first build in the IDE needs 2.8GB of memory and one minute compilation time. After the third build I usually have to restart the ide, because compiliation time would be too long. Perhaps its time for a 64bit IDE.

It is not about small executables. It's about the delphi IDE which becomes which becomes unresponsive and suffers from long compile and link times (including cases of EOutOfMemory). For example, we have an internal library using derived generic TList class. And we have a lot of business model objects stored in this list class. For each and every generic list object type, all methods of TList are compiled again into the executable, even if they're doing the same thing. Perhaps with some trickery one would be able to replace this list class with a non-generic version. I only wanted to add the comment that it is nice to have clean and working generic code but that it has a downside, too.

This looks very good (and works)! But please note that in the compiled result you will get an instance of this function for every type <T> you use it for - even if it likely does the same for all TObjects which you pass in. If you have a lot of types and a lot of utility functions like this, this will increase your executable file.

Just noticed that TPopupActionBar (using Delphi 10.2) does seem to use the correct font color. Anyways, I find the look of the classic menus not very readable.