Informing about the establishment of a defect on Embarcadero

[Михаил Рогов]

Hello,

We created a issue, witch use sources from your repo.

Link on issue: https://quality.embarcadero.com/browse/RSP-23375

[Stefan Glienke]

This is partially the case because the generated dcus are containing more than they should (see the issue I referenced in the comment).

However due to the fact that the collection types especially the more complex ones (like dictionary) are rather fat they increase the size of each dcu. This is something I am going to address in 1.3 but it's not an easy task to do (especially since the issue of still pulling in types into the dcu is there).

What I can suggest if you have many different units that call for instance TCollections.CreateDictionary<x,y> where x and y are the same to make a dedicated unit with a function that then calls TCollections.Create.... - that way the implementing type only manifests in this unit.

For example with the LinuxTestWithSpring project I did the following:

Add a unit with this content:

unit CollectionUtils;

interface

uses
  Spring.Collections;

function CreateIntStrDict: IDictionary<Integer, string>;
function CreateIntIntStrDictDict: IDictionary<Integer, IDictionary<Integer, string>>;

implementation

function CreateIntStrDict: IDictionary<Integer, string>;
begin
  Result := TCollections.CreateDictionary<Integer, string>;
end;

function CreateIntIntStrDictDict: IDictionary<Integer, IDictionary<Integer, string>>;
begin
  Result := TCollections.CreateDictionary<Integer, IDictionary<Integer, string>>;
end;

end.

and reference this in the BigDcuUnit and call its functions. This reduces the binary bloat in each unit as it only manifests in CollectionUtils.dcu - on Win32 it then was less than 180K compared to 1140K (numbers are from an internal ongoing 1.3 develop branch with release config - not having debug symbols also reduces the size quite significantly).

I am really interested in getting this addressed on Embarcaderos and on my side - on my side there is only so much I can do (shrink generics, internally "fold" types) without making the same mess as in System.Generics.Collections (and fwiw they did not do it for TDictionary anyway).

[Stefan Glienke]

If you are still having trouble and/or are interested in helping improving the library and reducing problems resulting from generics please send me a message so I can guide you through some steps that you can try out to analyze and reduce/solve the problem.

[Михаил Рогов]

Hello.

We still having trouble. We use your example in our code for IList and Dictionary with simple type. This help us, but we have list's and dictionarie's with our classes and interfaces.

Also we replace all entry of TCollections.CreateList to TCollections.CreateObjectList and TCollections.CreateInterfacedList. And this help too. We reduce summary size of dcu/o files on 700 mb.

Now out big trouble in TCollections.CreateDictionary. One ad of TCollections.CreateDictionary adds in "o" file on linux ~7 mb.

We tried to use generic method like in your example:

type
  TSpringCollectionUtils = class
  public
    class function CreateDictionary<E, T>: IDictionary<E, T>;
  end

But this not help us. We see code bloat in binary.

We interesting to solve this problem and improve library, because we have big trouble on linux platform.

[Stefan Glienke]

Please send me an email so we can discuss this further (you can find it in any of my commits if you click on "view raw commit").

[Михаил Рогов]

Sended you an email

[Stefan Glienke]

This issue has been addressed as much as possible from my side in 2.0 and tests show significant improvements across the board regarding compiletime, memory usage during compiling/linking and binary size of dcus and final executable.

Any further optimizations are only possible from Embarcaderos side in releation to RSP-18080 which I keep pushing for whenever possible.