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
Comments (7)
-
repo owner -
repo owner - changed status to open
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.
-
reporter 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.
-
repo owner 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").
-
reporter Sended you an email
-
repo owner - changed milestone to 2.0
-
repo owner - changed status to resolved
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.
- Log in to comment
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:
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).